Cached interface dispatch for coreclr

[davidwrighton]

Enabling cached interface dispatch as an options for CoreCLR (should reduce memory usage/remove RWX pages, at the cost of reducing performance)

• Current implementation is only enabled in release builds for Apple platforms with restrictions on code generation
• On Debug/Checked builds of X64/Arm64 platforms it is possible to enable the feature by setting the DOTNET_UseCachedInterfaceDispatch environment variable to 1. (NOTE: Enabling this feature requires running on a processor which supports 128 bit compare and swap, which has implications on Linux X64 builds, and would have implications for Loongarch/RiscV if we enable the code there.)
• The strategy is to re-use the existing VirtualCallStubManager infrastructure for all non-code-generation driven lookups, but to replace the stub generation logic with the CachedInterfaceDispatch paths from NativeAOT.
• In addition, to support this, we need to extend the size of a Dispatch cell embedded in R2R images, so various parts of that logic are now capable of generating double pointer aligned dispatch cells when commanded. Infrastructure to set the right behavior for targetting apple platforms has not yet been implemented although the general purpose support is in place.

Known issues addressed before making a non-draft PR

• Env flag for swapping between cached interface dispatch and VSD when both features are enabled in the code
• Testing of normal scenarios
• Testing of diagnostic scenarios (No regressions in VSD mode, Cached Interface Dispatch also successfully steps)
• Consider enabling the resolve cache for cached interface dispatch scenarios (will not do until perf results show that the current scheme is slow)
• Enable support for R2R with cached interface dispatch
• Make the Indirection cell size 2 pointers instead of 4
• Free dispatch cache infrastructure on collectible assembly destruction
• Allocate cache chunks with LoaderHeap instead of malloc
• Move PalInterlockedCompareExchange128 to the PAL or minipal
• Actually correct construction of indirection cell for virtual dispatch on vtables

[dotnet-policy-service]

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

[kg]

If pSDFrame is &frame why are we indirecting through the pointer instead of using frame directly?

[janvorli]

This is due to historical reasons. Until recently (3 weeks ago), the frame was FrameWithCookie<StubDispatchFrame> and not just StubDispatchFrame. So the StubDispatchFrame * pSDFrame = &frame was used so that on every access we don't need to do casting. It isn't needed anymore.

[am11]

@davidwrighton is it supposed to exclude riscv64 and loongarch64? Test build has started to break:

ld.lld : error : undefined symbol: RhpVTableOffsetDispatchAVLocation [/runtime/src/tests/nativeaot/GenerateUnmanagedEntryPoints/GenerateUnmanagedEntryPoints.csproj] [/runtime/src/tests/build.proj]

[MichalStrehovsky]

@davidwrighton is it supposed to exclude riscv64 and loongarch64? Test build has started to break:

ld.lld : error : undefined symbol: RhpVTableOffsetDispatchAVLocation [/runtime/src/tests/nativeaot/GenerateUnmanagedEntryPoints/GenerateUnmanagedEntryPoints.csproj] [/runtime/src/tests/build.proj]

I think I have a fix in #113179