Make MethodDataObject::FillEntryDataForAncestor lazy per-level

[davidwrighton]

Summary

Follow-up to #130151. That PR optimized MethodTable::MethodDataObject::FillEntryDataForAncestor to pre-resolve virtual slots whose final vtable entry is NULL — slots that have never been overridden by a subclass nor called, and therefore cannot be the target of a MethodImpl, so they are safe to fill even when a MethodImpl exists somewhere in the inheritance chain. This avoids the expensive GetMethodDescForSlot_NoThrow fallback (O(N) in the number of methods in the type hierarchy) that otherwise makes MethodDataObject population O(V*N) for deep hierarchies with many un-overridden/uncalled virtuals — the shape that shows up in WPF startup (dotnet/wpf#11740).

However, that implementation produced the null-slot bitmap on the initial MethodTable (m_pDeclMT) and, to fill those slots across the hierarchy, added an eager loop that walked the entire parent chain (running an IntroducedMethodIterator at every level) on the very first PopulateNextLevel call. That defeats the class's lazy, one-level-per-PopulateNextLevel design and adds tail latency.

Change

MethodDataObject already retains a pointer to the initial MethodTable, so the "is this slot's final vtable entry NULL" question can be answered on demand from m_pDeclMT's canonical MethodTable at any level. This PR computes the set of un-overridden/uncalled slots per level instead:

• For each virtual slot introduced at the current level, when a MethodImpl exists at or below the current level, fill it only if its final vtable entry on m_pDeclMT's canonical MT is NULL.
• m_containsMethodImpl is monotonic across the most-derived → base walk, so at each level it reflects exactly the MethodImpls that can redirect slots introduced at that level (a MethodImpl at a more-base level targets lower slot numbers and cannot affect slots introduced further derived).

This removes the eager full-chain walk, the null-slot bitvector, and its heap allocation, restoring a single IntroducedMethodIterator per level while producing identical Decl/Impl MethodDesc data. Null slots are introduced at exactly one level (never overridden), so they are filled exactly once, at their introducing level.

Net: -167 / +36 lines; the method is now allocation-free under its LIMITED_METHOD_CONTRACT.

Validation

• Builds clean (CoreCLR Debug and Release, Windows x64).

• Ran a .NET 10 self-contained WPF app on a locally-built .NET 11 runtime (only the app's own binaries stay .NET 10; the full .NET 11 Microsoft.NETCore.App and .NET 11 WPF pack are used). WPF heavily exercises this exact path; the app renders correctly with no errors.

• Startup A/B vs current main (swapping only the matched clrjit/coreclr/System.Private.CoreLib trio), interleaved, medians of 60 iterations:

  Config	Median (ms)	Mean (ms)	Min	Max
  main (baseline)	1407.0	1435.1	1356.8	3190.8
  this PR	1395.7	1395.1	1359.0	1430.9

  Performance-neutral-to-slightly-faster at the median, with a much tighter tail (max 1431 ms vs 3191 ms) from removing the eager full-chain walk. (Absolute numbers are inflated because the framework here is not R2R/PGO-optimized for a dev coreclr; the comparison isolates this change.)

Note

This pull request was authored with assistance from GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR refactors MethodTable::MethodDataObject::FillEntryDataForAncestor to preserve MethodDataObject’s intended lazy, one-ancestor-per-PopulateNextLevel() population behavior when MethodImpls are present in the inheritance chain, while retaining the earlier optimization that pre-resolves “final vtable slot is NULL” virtuals to avoid O(V*N) fallback costs.

Changes:

• Removes the eager full-parent-chain walk and the null-slot bitvector (and its potential heap allocation) previously done during the first PopulateNextLevel() call.
• When m_containsMethodImpl is true, performs the “NULL final slot” check on-demand per level using m_pDeclMT’s canonical vtable to decide whether a virtual slot can be safely pre-resolved.
• Keeps non-virtual slot pre-resolution restricted to the most-derived m_pDeclMT level, as before.