[mono][wasm][AOT] CollectionsMarshal dictionary value-ref write is lost across GC

Start by extracting the attached reproducer and running the provided publish/Node loop; the failing evidence is the ref-gc rows in __PROBE__, where sum and readback diverge while the indexer and no-GC controls pass. Read Program.cs alongside Repro.csproj and main.mjs to confirm the forced collection and value-ref lifetime, then use the linked runtime issues as context. Done means every ref-gc row reports readback=9757946880 across fresh processes on both .NET 10 and .NET 11 RC3.

Description

In Node-hosted Mono browser-WASM AOT, a write through a dictionary value reference returned by CollectionsMarshal.GetValueRefOrNullRef can be silently lost if a GC occurs while the reference is live.

The addition produces the expected BigInteger, but a subsequent dictionary lookup returns the original value. The key remains present, with no insertion, removal, resize, or concurrent access while the reference is live.

• .NET 11 RC3: all forced-GC byref writes failed.
• .NET 10: the first forced-GC byref write in each fresh process failed; later calls in that process passed.
• Controls using the indexer across GC or the byref without GC passed on both versions.

Reproduction Steps

Reproducer package: mono-wasm-byref-gc-repro.zip

It contains .NET 10 and .NET 11 RC3 projects with identical C# source, pinned SDKs, a Node launcher, and instructions.

Relevant declarations copied from the attached Program.cs:

private sealed record Sample(string Mode, string Before, string Increment, string Sum, string Readback, int Collections);

[MethodImpl(MethodImplOptions.NoInlining)]
private static Sample RefProbe(Dictionary<int, BigInteger> map, bool collect) {
    BigInteger increment = new(2987424000L);
    ref BigInteger slot = ref GetSlot(map);
    BigInteger previous = slot;
    BigInteger sum = previous + increment;
    int before = GC.CollectionCount(GC.MaxGeneration);
    if (collect) {
        GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true, true);
    }
    slot = sum;
    BigInteger readback = map[7];
    GC.KeepAlive(map);
    return new(collect ? "ref-gc" : "ref-no-gc", previous.ToString(), increment.ToString(), sum.ToString(), readback.ToString(), GC.CollectionCount(GC.MaxGeneration) - before);
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static ref BigInteger GetSlot(Dictionary<int, BigInteger> map) => ref CollectionsMarshal.GetValueRefOrNullRef(map, 7);

Each dictionary starts with [7] = 6770522880. The full reproducer uses non-inlined creation and probe methods, creates the dictionary before await Task.Yield(), obtains the reference after resuming, and uses a separate dictionary for every trial and control.

Requirements: SDKs 10.0.402 and 11.0.100-rc.3.26522.148, each SDK's wasm-tools workload, and Node 24.22.1.

From the extracted archive root, in a POSIX-compatible shell:

for framework in net10 net11; do
  (
    cd "$framework" || exit 1
    dotnet workload install wasm-tools --skip-manifest-update &&
    dotnet publish Repro.csproj -c Release -o publish &&
    cp ../main.mjs publish/wwwroot/main.mjs
  ) || exit 1
done

for process in 1 2 3 4 5; do
  node net10/publish/wwwroot/main.mjs
  node net11/publish/wwwroot/main.mjs
done

Each process prints three trials of:

• ref-gc: write through the value ref after forced GC.
• indexer-gc: write through map[7] after forced GC.
• ref-no-gc: write through the value ref without forced GC.

The process exits with code 0 even when a write is lost; inspect the __PROBE__ rows.

Expected behavior

Every row should report:

previous=6770522880
increment=2987424000
sum=9757946880
readback=9757946880

Actual behavior

Failing ref-gc rows report sum=9757946880 but readback=6770522880. Every forced-GC row recorded one maximum-generation collection; every no-GC row recorded zero.

The same results were reproduced independently on Windows and Ubuntu. The counts below are per operating system, using five fresh processes per framework and three trials per process:

Observation	.NET 10	.NET 11 RC3
First ref-gc call lost write	5/5	5/5
Later same-process ref-gc calls lost write	0/10	10/10
indexer-gc controls lost write	0/15	0/15
ref-no-gc controls lost write	0/15	0/15

All processes completed all nine probe rows and printed __DONE__.

Regression?

No response

Known Workarounds

Copy the previous dictionary value with TryGetValue, compute the sum, then write using the dictionary indexer instead of retaining the value byref across GC. The indexer-with-GC control passed in the reported .NET 10 and .NET 11 runs.

Configuration

Hosts:

• Windows x64, build 10.0.26200
• Ubuntu 24.04.3 x64, Linux 6.18.55
• Node 24.22.1

Component	.NET 10	.NET 11 RC3
SDK	10.0.402	11.0.100-rc.3.26522.148
Mono browser-WASM runtime/AOT packs	10.0.13	11.0.0-rc.3.26522.148
Emscripten compiler	3.1.56	6.0.3

Both projects use Microsoft.NET.Sdk.WebAssembly, RunAOTCompilation=true, RuntimeIdentifier=browser-wasm, and the default WasmStripILAfterAOT=true.

Other information

Potentially related: dotnet/runtime#132306, dotnet/runtime#136489, and dotnet/runtime#130592.