@jkotas any more feedback?

I don't think micro benchmarks are going to be all that helpful so running against our own tests, that do a lot of validating wrapper clean-up, would help indicate the general impact.

Was the above done or are you looking for more feedback before doing that?

I wanted to make sure I had all feedback before I start running benchmarks.

I'll start on the benchmarking.

I did some local benchmarking with the ComWrappers/API test suite, as requested. I timed 10 runs of that test suite with the implementation in this PR and the implementation in main, both Release builds (10 runs to warm the processor cache, 10 runs for the measurements below) and got the following results:

• PR: 2.5039942 seconds
• Main: 2.5145364 seconds

Here is what the references between different managed object wrapper objects now are. I added the new static conditional weak table on ComWrappers:

graph TD
WO[wrapped object];
MOW["ManagedObjectWrapper (unmanaged struct)"];
MOWH[ManagedObjectWrapperHolder];
Releaser[ManagedObjectWrapperReleaser];
WO -->|ComWrappers static conditional weak table| MOWH;
WO -->|ComWrappers instance conditional weak table| MOWH;
MOWH --> WO;
MOWH --> MOW;
MOW -->|ref-counted handle| MOWH;
Releaser --> MOW;
MOWH --> Releaser;
WO -->|SyncBlock| MOW;

Adding the static ConditionalWeakTable fixes the problem of the pointers in the SyncBlock becoming dangling. But it can cause a memory leak where there was not one before. Before this change, when a ComWrappers instance was collected, all of its associated managed object wrappers became eligible for collection (assuming all refcounts were zero). After this change, the static ConditionalWeakTable keeps every ManagedObjectWrapperHolder ever made for an object alive until the wrapped object is collected.

This program should illustrate the memory leak:

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

unsafe class Program
{
    static Foo sRootedFoo = new Foo();

    static void Main()
    {
        Console.WriteLine($"I'm pid {Environment.ProcessId}");

        while (true)
        {
            for (int i = 0; i < 1000; i++)
            {
                AllocateAndFreeComWrappers();
            }
            for (int i = 0; i < 5; i++)
            {
                GC.Collect();
                GC.WaitForPendingFinalizers();
            }
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void AllocateAndFreeComWrappers()
    {
        ComWrappers cw = new StrategyBasedComWrappers();
        nint ptr = cw.GetOrCreateComInterfaceForObject(sRootedFoo, CreateComInterfaceFlags.None);
        Marshal.Release(ptr);
    }
}

[GeneratedComInterface]
[Guid("3faca0d2-e7f1-4e9c-82a6-404fd6e0aab8")]
internal partial interface IFoo
{
    void Method(int i);
}

[GeneratedComClass]
internal partial class Foo : IFoo
{
    public void Method(int i)
    {
    }
}

When run on .NET 9 NativeAOT, memory usage stays flat. On .NET 9 CoreCLR, it already leaks memory. So maybe this regression is not a big deal since it only effects NativeAOT?

On .NET 9 CoreCLR, it already leaks memory.

This is an intentional memory leak due to incorrect usage of ComWrappers. There is a strict mapping between the ComWrappers that created the wrapper and the wrapper itself. I don't think attempting to solve this is needed and I would argue the current CoreCLR implementation has less overhead than the native AOT solution with the additional ConditionalWeakTable.

@jkoritzinsky Thanks for trakcing the performance impact between the two implementations. Did you see the peak memory usage between the two?

I'll go check the peak memory usage and report back.

I compared the peak working set for the unit tests and got the following results:

PR: 28860 KiB
Main: 28920 KiB

I also compared a program that just creates 10000 RCWs that wrap 10000 CCWs of 10000 objects and got the following results:

PR: 164812 KiB
Main: 127544 KiB

I'll investigate what causes the increase (if it's just the table I added for diagnostics or something else) and see if I can mitigate it.

Looks like I can get the memory usage down, but I'll need to do the diagnostics work I was hoping to put off until another PR.

For a program that creates 1 million RCWs that wrap 1 million CCWs of 1 million objects, I get the following results:

Main: 1,027,288 KiB
PR: 1,339,048 KiB
PR with no special diagnostics assistance code in the runtime (no storing in the syncblock for diagnostics, no map for object->all ManagedObjectWrapperHolders): 640,480 KiB
PR with no syncblock, but has managed map for object->all ManagedObjectWrapperHolders: 779,548 KiB

Overall, it looks like we can switch, but we can't have both the syncblock info and the ConditionalWeakTables (which I guess makes sense).

I was able to get the diagnostics support switched over. I validated that the dumpobj, dumprcw, and dumpccw commands all work correctly with ComWrappers in this PR.