Place vtable slots deemed final by analysis into sealed vtable #97951
Conversation
Virtual method table slots typically go into vtable - a variable-length part of the `MethodTable` data structure. Virtual method table slots are always inherited by `MethodTable` of the derived class. This means that vtable slots that are introduced in a class that has many derived classes can be quite expensive. One example are arrays - array types inherit all virtual methods from `System.Array` and there's many arrays. We therefore have an optimization - if a virtual method is newly introduced, but it's sealed at the same time, we place it into a separate data structure - a "sealed vtable". Sealed vtable slots do not get inherited by derived classes. Because they don't get inherited, we also need to make sure all non-interface calls into this virtual method get devirtualized (virtual dispatch needs to be aware of the special lookup that happens for sealed slots and only interface resolution is aware of how to do that). This PR makes this optimization kick in more often - not just when method is `virtual sealed` in metadata (which effectively only happens for non-virtual method in C# implementing an interface), but also when it's virtual and nothing else overrides it in the program.
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsVirtual method table slots typically go into vtable - a variable-length part of the We therefore have an optimization - if a virtual method is newly introduced, but it's sealed at the same time, we place it into a separate data structure - a "sealed vtable". Sealed vtable slots do not get inherited by derived classes. Because they don't get inherited, we also need to make sure all non-interface calls into this virtual method get devirtualized (virtual dispatch needs to be aware of the special lookup that happens for sealed slots and only interface resolution is aware of how to do that). This PR makes this optimization kick in more often - not just when method is Cc @dotnet/ilc-contrib
|
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
The split between `Delegate` and `MulticastDelegate` is a wart that likely has some history behind it. Types that inherit from `Delegate` directly would not be considered delegates by the runtime. They need to inherit `MulticastDelegate. I can't find a reason why we'd need some useless base implementation of these methods that immediately gets overriden in `MulticastDelegate`. This deletes the useless base implementation and moves the useful implementation from `MulticastDelegate` to `Delegate`. This along with dotnet#97951 saves ~40 bytes per delegate `MethodTable` because the virtual methods can now be devirtualized or placed into the sealed vtable. We might be able to do even more since technically sealed virtuals could be reshuffled after the codegen phase and slots eliminated then.
MichalStrehovsky
changed the title
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| // not physical. | ||
| if (method.Signature.IsStatic && !isInterfaceMethod) | ||
| // If the owning type is already considered sealed, there's little benefit in placing the slots | ||
| // in the sealed vtable: the sealed vtable has these properties: |
There was a problem hiding this comment.
What are the downsides of keeping this simple and placing them in the sealed vtable? Are you trying to save the extra pointer to the sealed vtable?
There was a problem hiding this comment.
Yep, the extra pointer to the vtable. The old logic was just method.IsFinal && method.IsNewSlot so we didn't even look whether the type is sealed. Now we end up doing this for a lot more methods, often on valuetypes where it makes little sense.
The split between `Delegate` and `MulticastDelegate` is a wart that likely has some history behind it. Types that inherit from `Delegate` directly would not be considered delegates by the runtime. They need to inherit `MulticastDelegate. I can't find a reason why we'd need some useless base implementation of these methods that immediately gets overriden in `MulticastDelegate`. This deletes the useless base implementation and moves the useful implementation from `MulticastDelegate` to `Delegate`. This along with #97951 saves ~40 bytes per delegate `MethodTable` because the virtual methods can now be devirtualized or placed into the sealed vtable. We might be able to do even more since technically sealed virtuals could be reshuffled after the codegen phase and slots eliminated then.
Virtual method table slots typically go into vtable - a variable-length part of the
MethodTabledata structure. Virtual method table slots are always inherited byMethodTableof the derived class. This means that vtable slots that are introduced in a class that has many derived classes can be quite expensive. One example are arrays - array types inherit all virtual methods fromSystem.Arrayand there's many arrays.We therefore have an optimization - if a virtual method is newly introduced, but it's sealed at the same time, we place it into a separate data structure - a "sealed vtable". Sealed vtable slots do not get inherited by derived classes. Because they don't get inherited, we also need to make sure all non-interface calls into this virtual method get devirtualized (virtual dispatch needs to be aware of the special lookup that happens for sealed slots and only interface resolution is aware of how to do that).
This PR makes this optimization kick in more often - not just when method is
virtual sealedin metadata (which effectively only happens for non-virtual method in C# implementing an interface), but also when it's virtual and nothing else overrides it in the program.Cc @dotnet/ilc-contrib