-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
More cleanups in assembly loader area #63157
Conversation
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsIn progress. The goal is to simplify DomainFile/DomainAssembly and merge them into a single entity.
|
src/coreclr/vm/ceeload.cpp
Outdated
@@ -3284,7 +3264,7 @@ Module::GetAssemblyIfLoaded( | |||
} | |||
|
|||
if (pDomainAssembly && pDomainAssembly->IsLoaded()) | |||
pAssembly = pDomainAssembly->GetCurrentAssembly(); // <NOTE> Do not use GetAssembly - that may force the completion of a load | |||
pAssembly = pDomainAssembly->GetAssembly(); // <NOTE> Do not use GetAssembly - that may force the completion of a load |
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.
The comment now contradicts the code... ?
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.
Right. I think the comment was not correct for quite a while. There were no sideeffects with GetCurrentAssembly
either. Perhaps some time ago there was a distinction.
I haven't looked through everything fully yet, but I'm wondering - can you point me to the place where we already have a check which fails to load assemblies with multiple modules? I'm also wondering if we should somehow adapt managed reflection APIs accordingly - like obsolete some of the APIs which handle multi-module assemblies and such. |
runtime/src/coreclr/vm/ceeload.cpp Line 3488 in daa2965
All code paths throw some kind of exception. The most "normal" outcome is |
It's interesting that we go through the trouble of trying to load it - only to get a name to include in the exception. For another time 😄 |
Adapting managed API would be an interesting task. The abstraction of a module kind of still exists. Assembly has identity and module contain implementation. It is just that we allow only one module per assembly now, which means assembly and module are always the same file. In some reflection APIs like in dynamic codegen the layering is very clear - an assembly contains modules (only one now, I assume) and that contains code. |
Maybe there is nothing to do on the managed APIs (other than updating docs)... I was just thinking about all of the other things this may impact. |
BTW It feels like the responsibilities of |
I think the PR is at the logical point where it makes sense to review/merge. |
Rebased onto recent main and fixed accumulated merge conflicts. |
I think the PR is at the logical point where it makes sense to review/merge. |
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.
where we already have a check which fails to load assemblies with multiple modules
Do we have tests for this? Haven't made it through everything yet, but if we don't have existing tests, it might be good to add something to verify the expected (failure) behaviour.
Maybe there is nothing to do on the managed APIs (other than updating docs)... I was just thinking about all of the other things this may impact.
+1 for updating docs. I think the APIs should behave the same before/after this PR (right?), but it is a good opportunity to think through what docs might need updating. Some possible non-documented cases that I believe are not supported and will error:
AssemblyBuilder.DefineDynamicModule
: if a module is already defined (even if it is a different name)Assembly.GetModules
: if not reflection-only and has multiple modulesDllImportAttribute
: using assembly display name as part of DLL name per remarks
// The runtime has the notion of "DomainAssembly", which is 1:1 with DebuggerModule | ||
// and thus 1:1 with CordbModule. The CordbModule hash table on the RS now uses | ||
// the DomainFile as the key instead of DebuggerModule. This is a temporary | ||
// the DomainAssembly as the key instead of DebuggerModule. This is a temporary | ||
// workaround to facilitate the removal of DebuggerModule. | ||
// </TODO> |
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.
Does this TODO still make sense now that we don't have shared/multiple domains?
cc @dotnet/dotnet-diag
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.
A TODO from 2002 is most certainly obsolete. I would not know what needs to be done here though. I just tried not to mention things that no longer exist.
I like the part that TODO is tagged by a date. :-)
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.
DebuggerModule has had a few more things that started hanging off it. It'd be nice to clean but it hasn't happened. I think this crumble is a good hint of what to update in the case of such a transition.
I think this is better handled as a separate workitem just to separate it from mostly mechanical refactoring. I think this change does not change any behavior. It is a halting problem to prove that, but from the nature of the changes the chances are relatively low. |
I have added a workitem #64367 to track reviewing behaviors related to multimodule assemblies. |
Thanks!!! |
The goal is to simplify DomainFile/DomainAssembly and merge them into a single entity.
Coreclr does not have multimodule assemblies. With such assumption things can be simpler.