[Java.Interop] Lazily allocate peer member caches - #12701

Summary

• allocate instance/static method and field caches only on first use
• allocate the managed-subclass constructor cache only when a derived constructor path is needed
• share lock-free cache publication through a generic GetOrCreate<TKey, TValue>() helper
• atomically detach and clear allocated caches during disposal
• cover deferred allocation and concurrent first use

Analysis

Across Mono.Android for API 37, the types in our bindings have the following numbers of methods and fields:

This means that for most types, we should not be allocating a heavy ConcurrentDictionary for instance fields, static methods, and static fields. It's also possible that for some binding types we won't call even a single of their methods even though their static constructor runs. It makes sense to reduce allocations and reduce gc pressure here.

Results

A Release trimmed CoreCLR arm64 app created from dotnet new maui --sample-content was measured through first window focus on a Samsung A16.

Current main eagerly allocates approximately 1,347 peer cache dictionaries (~274 KiB at the measured 208 B per empty dictionary). With this change, first launch allocated 273 dictionaries (~55 KiB), avoiding about 1,074 dictionary allocations / 218 KiB gross managed allocation.

Repeated process-cold launches allocated 271–273 dictionaries (average 272):

The eager counts differ by one because one managed-subclass constructor path creates an additional JniInstanceMethods helper; only primary JniPeerMembers instances own the field/static caches.

The earlier instance-method-only version avoided about 67 dictionaries (~14 KiB); most savings come from deferring the other four caches.

Startup timing

A final all-cache A/B used 64 paired process-cold launches in four package-ID crossover blocks on the Samsung A16 (Release trimmed CoreCLR arm64, speed-compiled packages, animations disabled, alternating order, 27.6–28.0 °C):

The paired delta was −11.55 ms (−0.52%), favoring this PR, but was not statistically significant: 95% t interval [−28.06, +4.97] ms, bootstrap interval [−27.98, +4.16] ms, with 36/64 wins and one tie.

The honest conclusion is no measurable startup regression or improvement. Reduced managed allocation and retained heap are the demonstrated benefits.

Concurrent Dispose() and cache access remains unsupported, as before. Interlocked.Exchange() atomically detaches each cache visible to disposal but is not a disposed-state guard for stale references.

Retained startup heap

Two startup GC dumps per revision were collected after first window focus from the same Release trimmed CoreCLR arm64 dotnet new maui --sample-content app on Samsung A16. dotnet-gcdump collect induced a Gen2 GC, so values are live retained objects.

The targeted cache dictionary counts were 1,141/1,126 on current main versus 276/274 with this PR, avoiding 865/852 retained dictionaries. The entire retained ConcurrentDictionary delta is exactly these Java.Interop caches.

Useful cache contents were unchanged: JniMethodInfo counts were 818/815 for both revisions, JniFieldInfo was 36 for both, and method, field, and subclass node counts were unchanged. The dumps show removal of empty containers only.

Tests

• Java.Interop Debug build: 0 warnings, 0 errors
• focused JniPeerMembersTests: 12 passed, 1 skipped
• full Java.Interop-Tests: 711 passed, 6 skipped, 0 failed