[TrimmableTypeMap] Fix thread safety in TrimmableTypeMap.Initialize

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>[TrimmableTypeMap] Fix thread safety in TrimmableTypeMap.Initialize()</issue_title>
<issue_description>Part of #10788

Problem

TrimmableTypeMap.Initialize() has a race condition. The Interlocked.CompareExchange correctly ensures only one instance wins the singleton slot, but the losing thread still proceeds to call RegisterBootstrapNativeMethod():

// TrimmableTypeMap.cs:41-48
internal static void Initialize()
{
    var instance = new TrimmableTypeMap();
    var previous = Interlocked.CompareExchange(ref s_instance, instance, null);
    Debug.Assert(previous is null, "TrimmableTypeMap must only be created once.");
    instance.RegisterBootstrapNativeMethod();  // runs even if CompareExchange lost
}

If two threads race on Initialize():

1. Both create a TrimmableTypeMap instance (expensive — scans type map attributes)
2. Only one wins the CompareExchange
3. Both call RegisterBootstrapNativeMethod() — the losing thread registers on its discarded instance, which is a no-op, but it still creates JNI types and calls RegisterNatives unnecessarily

Fix

Add an early return guard after the CompareExchange:

internal static void Initialize()
{
    var instance = new TrimmableTypeMap();
    var previous = Interlocked.CompareExchange(ref s_instance, instance, null);
    if (previous is not null)
        return;
    instance.RegisterBootstrapNativeMethod();
}

Impact

Low — Initialize() is typically called once during startup. But the fix is trivial and prevents unnecessary work + potential double JNI registration.</issue_description>

Comments on the Issue (you are @copilot in this section)

[simonrozsival]

@copilot try again

[simonrozsival]

@copilot continue

[Copilot]

@copilot continue

The fix has been applied in d0513d7. The Initialize() method now returns early if another thread already won the CompareExchange, preventing the losing thread from calling RegisterNatives() unnecessarily.

[Copilot]

Pull request overview

Adjusts TrimmableTypeMap.Initialize() in Mono.Android to avoid redundant JNI native registration work when multiple threads race to initialize the singleton, supporting the Trimmable Type Map runtime path.

Changes:

• Add an early-return guard after Interlocked.CompareExchange so only the winning initializer registers JNI natives.
• Remove the prior debug-only “must only be created once” assertion behavior.

[Copilot]

Debug.Assert was removed, so using System.Diagnostics; in this file is now unused. Please remove the unused using to avoid analyzer/warning failures in builds that treat warnings as errors.

[Copilot]

With the early-return, a concurrent caller can return from Initialize() while the winning thread is still in the middle of instance.RegisterNatives(). Since the method’s contract is “initialize and register natives”, consider ensuring other threads either wait for registration to complete (e.g., via Lazy/LazyInitializer or an init-state gate) or only publish s_instance after native registration has succeeded.

[simonrozsival]

@copilot address the review comments. Use a static Lock object instead of Interlocked.

[Copilot]

@copilot address the review comments. Use a static Lock object instead of Interlocked.

Done in 5a8136b. The implementation now uses a static Lock with double-checked locking. s_instance is only assigned after RegisterNatives() completes, so concurrent callers either wait inside the lock or see the fully-initialized instance. Also removed the now-unused using System.Diagnostics;.