Support precompiling CCW vtables in ILC cctor interpreter (Native AOT)

[Sergio0694]

Related to #79204

As we're migrating the Microsoft Store to Native AOT, and also adopting Native AOT in Windows components, we're investigating all opportunities to improve performance and reduce size, as well as regressions from things that were handled better on .NET Native. One area that seems to be quite impactful due to the way the WinRT projections and interop stack work, is the codegen around CCW vtables. Currently, ILC is not able to fold these into constant blobs, meaning that we pay the initialization cost + the static constructor (and the cctor checks on every access) for:

• Every single IDIC implementation (ie. for every single projected interface)
• Every single statically visible generic instantiation (for async tasks, delegate types, collection types)

These add up to thousands of types, so there's a pretty good opportunity for improvements. .NET Native handled this via some special logic to initialize constant blobs for vtables, which Native AOT doesn't have. However, my thinking is that we could simply extend the support in ILC to interpret static constructor by making a couple of required APIs intrinsics, and making sure it can recognize common patterns.

For APIs that would need to be handled as intrinsics by ILC:

• ComWrappers.GetIUnknownImpl
• RuntimeHelpers.AllocateTypeAssociatedMemory

Next to this, it should also be able to handle common patterns around:

• Copying constant vtables (from other pre-initialized vtable pointers) to memory locations
• Assigning [UnmanagedCallersOnly] method addresses to vtable slots

Ideally, ILC should be able to fold all of these vtables into a constant blob (like an RVA span field), and trim the cctor entirely.

Our expectation is that this should be doable because Native AOT can rely on the fact that:

• Types aren't unloaded (so it doesn't matter where each vtable is allocated, it can be any memory)
• The address of all [UnmanagedCallersOnly] method (or, any method in general) should be a constant
• The address of each entry from ComWrappers.GetIUnknownImpl should also be a constant that can be hardcoded by ILC

Common patterns

I've prepared snippet with the common patterns we'd need handling:

• IUnknown vtable
• Vtables built by directly assigning to vtable offsets
• Vtables built by assigning through a vtable type

CCW patterns (click to expand)

using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

#pragma warning disable

// 1) Base IUnknown vtable
internal static unsafe class IUnknownImpl
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        IUnknownVftbl* vftbl = (IUnknownVftbl*)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IUnknownImpl), sizeof(IUnknownVftbl));

        ComWrappers.GetIUnknownImpl(
            fpQueryInterface: out *(nint*)&vftbl->QueryInterface,
            fpAddRef: out *(nint*)&vftbl->AddRef,
            fpRelease: out *(nint*)&vftbl->Release);

        return (nint)vftbl;
    }
}

// 2) Example vtable with direct assignments
internal static unsafe class IInspectableImpl1
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        void** vftbl = (void**)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IInspectableImpl1), sizeof(void*) * 6);

        *(IUnknownVftbl*)vftbl = *(IUnknownVftbl*)IUnknownImpl.AbiToProjectionVftablePtr;

        vftbl[3] = (delegate* unmanaged[MemberFunction]<void*, uint*, Guid**, int>)&GetIids;
        vftbl[4] = (delegate* unmanaged[MemberFunction]<void*, nint*, int>)&GetRuntimeClassName;
        vftbl[5] = (delegate* unmanaged[MemberFunction]<void*, int*, int>)&GetTrustLevel;

        return (nint)vftbl;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetIids(void* thisPtr, uint* iidCount, Guid** iids)
    {
        *iidCount = 0;
        *iids = null;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetRuntimeClassName(void* thisPtr, nint* className)
    {
        *className = default;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetTrustLevel(void* thisPtr, int* trustLevel)
    {
        *trustLevel = 0;

        return 0;
    }
}

// 3) Example vtable with vtable assignments
internal static unsafe class IInspectableImpl2
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        IInspectableVftbl* vftbl = (IInspectableVftbl*)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IInspectableImpl2), sizeof(IInspectableVftbl));

        *(IUnknownVftbl*)vftbl = *(IUnknownVftbl*)IUnknownImpl.AbiToProjectionVftablePtr;

        vftbl->GetIids = &GetIids;
        vftbl->GetRuntimeClassName = &GetRuntimeClassName;
        vftbl->GetTrustLevel = &GetTrustLevel;

        return (nint)vftbl;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetIids(void* thisPtr, uint* iidCount, Guid** iids)
    {
        *iidCount = 0;
        *iids = null;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetRuntimeClassName(void* thisPtr, nint* className)
    {
        *className = default;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetTrustLevel(void* thisPtr, int* trustLevel)
    {
        *trustLevel = 0;

        return 0;
    }
}

public unsafe struct IUnknownVftbl
{
    public delegate* unmanaged[MemberFunction]<void*, Guid*, void**, int> QueryInterface;
    public delegate* unmanaged[MemberFunction]<void*, uint> AddRef;
    public delegate* unmanaged[MemberFunction]<void*, uint> Release;
}

internal unsafe struct IInspectableVftbl
{
    public delegate* unmanaged[MemberFunction]<void*, Guid*, void**, int> QueryInterface;
    public delegate* unmanaged[MemberFunction]<void*, uint> AddRef;
    public delegate* unmanaged[MemberFunction]<void*, uint> Release;
    public delegate* unmanaged[MemberFunction]<void*, uint*, Guid**, int> GetIids;
    public delegate* unmanaged[MemberFunction]<void*, nint*, int> GetRuntimeClassName;
    public delegate* unmanaged[MemberFunction]<void*, int*, int> GetTrustLevel;
}

[dotnet-policy-service]

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

[MichalStrehovsky]

my thinking is that we could simply extend the support in ILC to interpret static constructor by making a couple of required APIs intrinsics, and making sure it can recognize common patterns.

That sounds like a bit of an interpreter rewrite I would rather avoid. ¹

.NET Native handled this via some special logic to initialize constant blobs for vtables, which Native AOT doesn't have

.NET forefathers already knew about a need to emit vtables into executables and the .NET file format has had a representation for "memory block with function pointers in it declared statically" for good 20 years. I would not be opposed to using the existing encoding. One cannot generate it with C#, but it would be possible to introduce it through IL rewriting, or generating a new .NET assembly at build time (through a new tool, or with ILASM, or whatever) and injecting it into compilation. Or try luck getting this into C# proper.

In IL it looks like this:

//
// Assemble with `ilasm /x64 /flags=0 vtfixup.il` and run on .NET framework or CoreCLR
//

.mscorlib

.assembly vtfixuptest { }

// Declare RVA static field of type int64 (enough space for a pointer) placed at location FixedUpBlob in the image
.field static int64 myVTable at FixedUpBlob

// Declare data at location FixedUpBlob within the image. The first 4 bytes are the token (0x06000002) of the target method
// the rest is padded because at runtime, the CLR is going to rewrite the token by a function pointer
.data FixedUpBlob = bytearray (0200000600000000)

// One 64-bit fixup is present in FixedUpBlob
.vtfixup [1] int64 at FixedUpBlob

.method public static int32 Main()
{
  .entrypoint
  // Load address of myVTable field
  ldsflda int64 myVTable

  // Dereference nint-sized pointer
  ldind.i

  // Indirect call to the location we read above
  calli int32()

  ret
}

// Second method in file, ILASM will assign token 06000002 to it.
.method public static int32 Test()
{
  ldc.i4 42
  ret
}

I think this would work well with trimming - same way how RVA-static fields work with trimming in general.

The only disadvantage is that on a JIT-based .NET runtime, these fixups are processed eagerly at module load so if there's many of them, it could slow down startup. But it's questionable by how much - I think C++/CLI uses this so probably it's not terrible. It would be super-efficient with AOT without having to rely on an cctor optimization to kick in.

Footnotes

1. Having to model assignments into fields that have pointers in them (function pointers in this case but also applies to object references) is incompatible with the memory model of the static constructor interpreter. The interpreter represents all values as byte arrays (i.e. working with int means we're actually working with a byte array that has four elements; working with a struct that has two int fields means working with an 8-element byte array). Addresses of things (function addresses, or reference type addresses) are not known until runtime and interpreter cannot model them as bytes. It would require a symbolic representation. Feels like a pretty major rewrite. ↩

[jkotas]

That sounds like a bit of an interpreter rewrite I would rather avoid.

Yes, it is a significant change, but it keeps the overall flow simple (no new build steps) and it opens an opportunity for interpreting more constructs.

If we do not want to do the general support in the interpreter, we may consider a pattern matching of the specific shape used for vtable initialization. It is equivalent of the IL rewriting approach.

it would be possible to introduce it through IL rewriting

If the IL rewriting is an independent step, how would you make it work with IUknown slots that are provided by the runtime?

[jkotas]

I think this would work well with trimming

I do not think that the trimmer supports vtfixups today.

Binaries with vtfixups are treated as IJW binaries in general. vtfixups introduce writeable data section. Writeable data sections in IL binaries are part of IJW feature set that is Windows-specific, not supported by many tools, etc.

[MichalStrehovsky]

Yes, it is a significant change, but it keeps the overall flow simple (no new build steps) and it opens an opportunity for interpreting more constructs.

It mostly opens up new opportunities for bugs in the interpreter. It was never written to have support for this and I don't have confidence in retrofitting it - it would ideally be rewritten with the new model in mind, maybe taking small harmless pieces. It's the reason why #84431 (comment) went nowhere too.

If the IL rewriting is an independent step, how would you make it work with IUknown slots that are provided by the runtime?

This could be a new kind of fixup - looks like there's free bits and we only need one:

runtime/src/coreclr/inc/corhdr.h

Lines 149 to 154 in bee9dd2

	// V-table constants
	COR_VTABLE_32BIT =0x01, // V-table slots are 32-bits in size.
	COR_VTABLE_64BIT =0x02, // V-table slots are 64-bits in size.
	COR_VTABLE_FROM_UNMANAGED =0x04, // If set, transition from unmanaged.
	COR_VTABLE_FROM_UNMANAGED_RETAIN_APPDOMAIN=0x08, // NEW
	COR_VTABLE_CALL_MOST_DERIVED =0x10, // Call most derived method described by

I do not think that the trimmer supports vtfixups today.

I meant it can be made to work with trimming. Tools may not support it, but it is part of the file format spec, so it's all tool bugs. This could also be made native AOT only feature of CsWinRT. CsWinRT already does things that are only for native AOT. I don't think we'd need to make it work with ILLink as a min bar (if it's only consumed by native AOT).

[MichalStrehovsky]

#114067 has a sketch of implementation that doesn't handle the ComWrappers.GetIUnknownImpl case (that I would also not be excited to hardcode into the interpreter either).

[jkotas]

it is part of the file format spec, so it's all tool bugs

Number of IJW-specific bits made it into the file format spec. We support them only for scenarios where IJW is supported in general. I do not think it is interesting to support them outside that. We can clarify this in ECMA augments.

[Sergio0694]

Thank you both for taking a look at this! This is all very promising 😄

Just to clarify, is my understanding correct then that the intention is to just make things work via this .vtfixup table (and to add some way to also integrate the ComWrappers.GetIUnknownImpl vtable slots into that), and to drop the ILC interpreter idea entirely? For CsWinRT, I assume this means we'd need to use some kind of IL weaving/rewriting at least at first, until C# gets language support for this (if ever)? We'd be targeting .NET 10 as a baseline for CsWinRT 3.0, so that would seem viable for us. Should we open a language proposal to track that? And what would that look like exactly? Happy to also sync offline to write a proposal, if that helps.

[jkotas]

make things work via this .vtfixup table

I am not fan of this solution. .vtfixup is part of IJW-specific feature set and I think it is best for it to stay that way.

If we do not want to build generic interpreter support to handle this, I think that the next best option is to pattern match static constructors with specific shape in the NAOT compiler.

Ie. instead of if (RVA static with vtfixup) { emit unmanaged vtable }, do if (static constructor with specific shape) { emit unmanaged vtable; }. We can discuss the specific shape that it would need to match.

I assume this means we'd need to use some kind of IL weaving/rewriting

Right.

C# gets language support for this (if ever)?

I do not think that this niche feature can ever make it to C# as first-class concept.

[Sergio0694]

Given all of that:

• You'd prefer not to use .vtfixup
• We'd need IL weaving/rewriting (which I'd really feel more comfortable avoiding)
• We're unlikely to ever get language support

Then yeah some pattern matching seems completely reasonable to me. To be clear, when I originally suggested relying on the ILC interpreter, I was thinking of some kind of pattern matching as well. As in, just let us know how exactly you'd want us to write code in our static constructors to initialize vtables so that the interpreter can fully fold them into some RVA of some kind.

Mentioned this to Michal offline, posting it here too for context: if it helps at all, we'd also be fine only supporting 64 bits.

"We can discuss the specific shape that it would need to match."

I mentioned our 3 main examples in my first post, copying it here too for context. We basically have 3 cases:

• IUnknown vtable
• Vtables built by directly assigning to vtable offsets
• Vtables built by assigning through a vtable type

CCW patterns (click to expand)

using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

#pragma warning disable

// 1) Base IUnknown vtable
internal static unsafe class IUnknownImpl
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        IUnknownVftbl* vftbl = (IUnknownVftbl*)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IUnknownImpl), sizeof(IUnknownVftbl));

        ComWrappers.GetIUnknownImpl(
            fpQueryInterface: out *(nint*)&vftbl->QueryInterface,
            fpAddRef: out *(nint*)&vftbl->AddRef,
            fpRelease: out *(nint*)&vftbl->Release);

        return (nint)vftbl;
    }
}

// 2) Example vtable with direct assignments
internal static unsafe class IInspectableImpl1
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        void** vftbl = (void**)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IInspectableImpl1), sizeof(void*) * 6);

        *(IUnknownVftbl*)vftbl = *(IUnknownVftbl*)IUnknownImpl.AbiToProjectionVftablePtr;

        vftbl[3] = (delegate* unmanaged[MemberFunction]<void*, uint*, Guid**, int>)&GetIids;
        vftbl[4] = (delegate* unmanaged[MemberFunction]<void*, nint*, int>)&GetRuntimeClassName;
        vftbl[5] = (delegate* unmanaged[MemberFunction]<void*, int*, int>)&GetTrustLevel;

        return (nint)vftbl;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetIids(void* thisPtr, uint* iidCount, Guid** iids)
    {
        *iidCount = 0;
        *iids = null;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetRuntimeClassName(void* thisPtr, nint* className)
    {
        *className = default;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetTrustLevel(void* thisPtr, int* trustLevel)
    {
        *trustLevel = 0;

        return 0;
    }
}

// 3) Example vtable with vtable assignments
internal static unsafe class IInspectableImpl2
{
    public static nint AbiToProjectionVftablePtr { get; } = GetAbiToProjectionVftablePtr();

    private static nint GetAbiToProjectionVftablePtr()
    {
        IInspectableVftbl* vftbl = (IInspectableVftbl*)RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(IInspectableImpl2), sizeof(IInspectableVftbl));

        *(IUnknownVftbl*)vftbl = *(IUnknownVftbl*)IUnknownImpl.AbiToProjectionVftablePtr;

        vftbl->GetIids = &GetIids;
        vftbl->GetRuntimeClassName = &GetRuntimeClassName;
        vftbl->GetTrustLevel = &GetTrustLevel;

        return (nint)vftbl;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetIids(void* thisPtr, uint* iidCount, Guid** iids)
    {
        *iidCount = 0;
        *iids = null;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetRuntimeClassName(void* thisPtr, nint* className)
    {
        *className = default;

        return 0;
    }

    [UnmanagedCallersOnly(CallConvs = [typeof(CallConvMemberFunction)])]
    private static int GetTrustLevel(void* thisPtr, int* trustLevel)
    {
        *trustLevel = 0;

        return 0;
    }
}

public unsafe struct IUnknownVftbl
{
    public delegate* unmanaged[MemberFunction]<void*, Guid*, void**, int> QueryInterface;
    public delegate* unmanaged[MemberFunction]<void*, uint> AddRef;
    public delegate* unmanaged[MemberFunction]<void*, uint> Release;
}

internal unsafe struct IInspectableVftbl
{
    public delegate* unmanaged[MemberFunction]<void*, Guid*, void**, int> QueryInterface;
    public delegate* unmanaged[MemberFunction]<void*, uint> AddRef;
    public delegate* unmanaged[MemberFunction]<void*, uint> Release;
    public delegate* unmanaged[MemberFunction]<void*, uint*, Guid**, int> GetIids;
    public delegate* unmanaged[MemberFunction]<void*, nint*, int> GetRuntimeClassName;
    public delegate* unmanaged[MemberFunction]<void*, int*, int> GetTrustLevel;
}

We can ensure that all our vtables in CsWinRT fall into one of these 3 buckets.
Do you imagine this new pattern matching would be able to handle these, possibly with some tweaks on our end?