Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crossgen2 determinism fixes #164
Crossgen2 determinism fixes #164
Changes from 1 commit
6f71413
d8c3522
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Just mention the name of the API we're calling here (
GetILBytes
) to reduce confusion. There's no GetAllBytes here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using Lazy to avoid writing our own double-checked locking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like what Jan suggested here, to use
Interlocked.CompareExchange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should rather use
Interlocked.CompareExchange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong: this will cause missing entries in the _manifestAssemblies (the bug that I fixed recently).
The right way to fix this is to get rid of _manifestAssemblies, and emit a sorted version of _assemblyRefToModuleIdMap in GetData(), sorted by module ID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And make _assemblyRefToModuleIdMap a
Dictionary<AssemblyName, int>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: would be nice to follow the same convention we have in other places:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we use a mix of both, but I like the
if (relocsOnly)
one better because of the indentation. Can I move all of them over to that one?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean the ones which return trivially like that. There are some legitimate uses of it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, leave it the way it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not see why we would ever want to remove the ILCache. Using pinned heap is not going to help. I would delete this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why we need it in the first place. This just seems to help releasing the pinning of the IL byte arrays to reduce GC fragmentation. The IL streams are saved on the type system method object, and there's no point in "caching".
My understanding is that the pinned heap will not have fragmentation. If so, we should just allocate the IL byte arrays on it, and remove the ILCache
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ILCache does not do any pinning. All pinning is done by jitinterface (CorInfoImpl.cs).
The purpose of ILCache is to cache the ILCode for given MethodDesc. The algorithm to compute ILCode for given MethodDesc is not cheap.
Pinned heap will have tend to have worse fragmentation than regular heaps because of it cannot be compacted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see what you mean. I debugged this, and it's more involved than I thought. I was under the impression that GetMethodIL() would directly just go to the EcmaMethodDesc's IL byte array that we load from metadata. This is why I was under the impression that the ILCache was used to free up the pins.
@SrivastavaAnubhav please delete the comment then.