-
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
Some more cleanups in Assembly/Binder area #59288
Conversation
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsIn progress. PR is mostly to run tests at this time.
|
@vitek-karas @elinor-fung - there is more refactoring possible, but I think the PR is getting bigger and harder to review, so maybe it is time to take a look at this iteration? |
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.
Looks great - just a couple of small things.
// This allows us to preferentially use the NGEN image if it is available. | ||
// BINDER_SPACE::Assembly represents a result of binding to an actual assembly (PEImage) | ||
// It is basically a tuple of 1) physical assembly and 2) binder which created/owns this binding | ||
// We also store whether it was bound using TPA list | ||
class Assembly |
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.
Opening a discussion (not for this PR): Should this be called something like BoundAssembly
or ResolvedAssembly
or so? I always found it super confusing to have two Assembly
types in the VM. And this one is not THE assembly, it's basically just a result of a successful bind (the runtime barely loaded the assembly at this point in fact, if at all).
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.
Yes. I think this needs to be renamed, but could not yet come up with a good name.
Mechanically speaking it could be BoundPEImage
, but I do not think PEImage
is itself a very intuitive name. Besides we are binding assemblies, not images.
The image is basically an assembly loaded into the process, but not yet "loaded" by the Loader (that would be a PEAssembly
). That is the distinction between PEImage
and PEFile
. They are not very related to each other and PEFile
is not necessarily a file. One is "loaded" by the Loader and another is input for the Loader.
We could benefit from a better naming, but better naming is not easy :-)
Also maybe having fewer things called Assembly could help too. We also have DomainAssembly
, for example.
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 have definitely gotten confused by the naming as well. I do think Bound/ResolvedAssembly
(I think we have more 'binding' naming in native and more 'resolving' in managed) would be better - but agree that we have lots of *Assembly
going on.
basically just a result of a successful bind
Not to be confused with BindResult
:)
I imagine there might be some future clean up / reconciling possible between those.
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 did not get into details of BindResult
yet. I assume it can represent a trial/failing attempt to bind with some context for the failure, but that is just a guess as I think we would need something like that and BindResult
is that.
I will definitely look at what can be shared or whether we need a separate type.
src/coreclr/vm/coreassemblyspec.cpp
Outdated
@@ -251,6 +221,8 @@ HRESULT BaseAssemblySpec::ParseName() | |||
|
|||
// Copy and own any fields we do not already own | |||
CloneFields(); | |||
|
|||
pAssemblyIdentity.SuppressRelease(); |
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.
Can we just stop using NewHolder
for this? The returned identity should always be owned by the ApplicationContext
(and does not get add ref-ed), so we should never want the backout/release.
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, we are not keeping pAssemblyIdentity
regardless, so no reason to mess with refcount.
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.
Thanks!
} | ||
EX_CATCH | ||
{ | ||
hr = E_FAIL; |
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.
Should this do GET_EXCEPTION()->GetHR()
(or use EX_CATCH_HRESULT_NO_ERRORINFO
) so that we can propagate the HRESULT from the exception?
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 have a feeling that this cannot fail. Since we are looking at instances of PEImage we must have already looked into matadata as a part of AssemblyName::Init
, but I am not completely sure, so I have a catch here.
GET_EXCEPTION()->GetHR()
sounds like a good idea
// This allows us to preferentially use the NGEN image if it is available. | ||
// BINDER_SPACE::Assembly represents a result of binding to an actual assembly (PEImage) | ||
// It is basically a tuple of 1) physical assembly and 2) binder which created/owns this binding | ||
// We also store whether it was bound using TPA list | ||
class Assembly |
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 have definitely gotten confused by the naming as well. I do think Bound/ResolvedAssembly
(I think we have more 'binding' naming in native and more 'resolving' in managed) would be better - but agree that we have lots of *Assembly
going on.
basically just a result of a successful bind
Not to be confused with BindResult
:)
I imagine there might be some future clean up / reconciling possible between those.
|
||
STDAPI BinderAcquireImport(PEImage* pPEImage, | ||
IMDInternalImport** pIMetaDataAssemblyImport, | ||
DWORD* pdwPAFlags); |
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.
These are only used in one place (each) now, right? Can we just put each in the .cpp that uses it?
PEKIND PeKind = peNone; | ||
DWORD dwPAFlags[2]; | ||
IF_FAIL_GO(BinderAcquireImport(pPEImage, &pIMetaDataAssemblyImport, dwPAFlags)); | ||
IF_FAIL_GO(AssemblyBinderCommon::TranslatePEToArchitectureType(dwPAFlags, &PeKind)); |
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: can we move SetArchitecture
up (or move this down) so they are closer together?
@@ -1406,11 +1382,8 @@ BOOL AssemblySpecBindingCache::StoreException(AssemblySpec *pSpec, Exception* pE | |||
pBinderToSaveException = pSpec->GetBinder(); | |||
if (pBinderToSaveException == NULL) | |||
{ | |||
if (!pSpec->IsAssemblySpecForCoreLib()) |
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.
Is IsAssemblySpecForCoreLib
still used or can we remove it?
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.
Yep, IsAssemblySpecForCoreLib
can be removed.
The failures are caused by #59541 |
BINDER_SPACE::Assembly
closer to what it represents. (basically a{PEImage, binder}
tuple )