-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Restore EETypeNode to the state before we deleted reflection blocking #94287
Restore EETypeNode to the state before we deleted reflection blocking #94287
Conversation
Contributes to dotnet#91704. When we deleted reflection blocking in dotnet#85810 we had to update `EETypeNode`/`ConstructedEETypeNode` to ensure any `MethodTable` also has metadata (constructed or not). This was needed because of how reflection was structured - we couldn't create a `RuntimeType` without knowing about the metadata. After the refactor in dotnet#93440, metadata is no longer a prerequisite to constructing a `RuntimeType`. The compiler can go back to optimizing away the metadata. This affects things like `typeof(Foo) == bar.GetType()`. No metadata is needed for this (and we do optimized the `Foo` MethodTable to unconstructed one) but we still had to generate metadata. Besides the rollback of EEType to the previous shape, this also has a bugfix for dotnet#91988 that was found later - interface types used in cast/dispatch should be considered constructed. I'm seeing 0.1 - 0.7% size saving.
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsContributes to #91704. When we deleted reflection blocking in #85810 we had to update The compiler can go back to optimizing away the metadata. This affects things like Besides the rollback of EEType to the previous shape, this also has a bugfix for #91988 that was found later - interface types used in cast/dispatch should be considered constructed. I'm seeing 0.1 - 0.7% size saving. Considering interfaces constructed doesn't result in pretty much any regressions and kind of makes sense (they don't have vtables and their interface list is not much cost). Cc @dotnet/ilc-contrib
|
Asserts in checked build |
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!
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
Contributes to #91704.
When we deleted reflection blocking in #85810 we had to update
EETypeNode
/ConstructedEETypeNode
to ensure anyMethodTable
gets metadata (constructed or not). This was needed because of how reflection was structured - we couldn't create aRuntimeType
without knowing about the metadata. After the refactor in #93440, metadata is no longer a prerequisite to constructing aRuntimeType
.The compiler can go back to optimizing away the metadata. This affects things like
typeof(Foo) == bar.GetType()
. No metadata is needed for this (and we do optimized theFoo
MethodTable to unconstructed one) but we still had to generate metadata for reflection stack sake.Besides the rollback of EEType to the previous shape, this also has a bugfix for #91988 that was found later - interface types used in cast/dispatch should be considered constructed.
I'm seeing 0.1 - 0.7% size saving. Considering interfaces constructed doesn't result in pretty much any regressions and kind of makes sense (they don't have vtables and their interface list is not much cost).
Cc @dotnet/ilc-contrib