Fix GC live lock by draining finalizers before GRef-threshold GC

[Copilot]

When GRef count exceeds the 90% threshold, every new GRef allocation triggers GC.Collect(). If the finalizer thread is saturated (e.g., processing Gen2GcCallback / ArrayPool<T>.Shared trimming), Java proxy finalizers never run, GRefs never drop, and the app enters a GC live lock.

• Add GC.WaitForPendingFinalizers() before GC.Collect() in CreateGlobalReference to drain the finalizer queue first, allowing Java proxy GRefs to be released before the next collection

if (gc >= JNIEnvInit.gref_gc_threshold) {
    Logger.Log (LogLevel.Warn, "monodroid-gc", gc + " outstanding GREFs. Performing a full GC!");
    System.GC.WaitForPendingFinalizers ();
    System.GC.Collect ();
}

Original prompt

---

This section details on the original issue you should resolve

<issue_title>GC live lock</issue_title>
<issue_description>### Android framework version

net9.0-android, net10.0-android (Preview)

Affected platform version

.NET 9, .NET 10

Description

We have an application that sometimes ends up in a vicious GC cycle live lock. The bug happens when the app goes through rapid UI section switching which results in a large number of Java proxy objects being allocated in a short time. What happens next is the following:

• GRef exhaustion: The number of Java Global References (GRefs) exceeds 90% of the system threshold (approximately > 46,800). Every subsequent GRef allocation (essentially any access to Java objects) triggers a Full GC.
• Full GC triggers a relatively expensive GC Bridge, where garbage collection is synchronized across both .NET and Java. This involves complex logic to reconcile references from one managed heap to the other; roughly 22k objects (give or take) enter this process.
• The GC bridge clears almost nothing, so the GRef count remains critical. The system gets stuck in a loop of constant garbage collection.
• Finalizer Bottleneck: The lack of memory recovery is partly because Java objects have finalizers, all of which run on the Finalizer Thread.
• The Finalizer Thread is preoccupied because every Full GC triggers a Gen2GcCallback, which runs trimming of various ArrayPool<T>.Shared array pools.

This creates a vicious cycle from which the application cannot recover.

Steps to Reproduce

See above. We don't have repro app but we do have GC dumps and sampling profiler traces from the app.

Did you find any workaround?

No, but I believe it may potentially help to call GC.WaitForPendingFinalizers() before GC.Collect() when the GRef threshold is reached here:

android/src/Mono.Android/Android.Runtime/AndroidRuntime.cs

Line 190 in db86d33

System.GC.Collect ();

Relevant log output

```</issue_description>

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

<comments>
</comments>

• Fixes GC live lock #10652

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[jonathanpeppers]

@copilot there are no changes. What did you even do?

[Copilot]

@copilot there are no changes. What did you even do?

The change is in commit 018c195 — it adds a single line System.GC.WaitForPendingFinalizers() before System.GC.Collect() in CreateGlobalReference() at src/Mono.Android/Android.Runtime/AndroidRuntime.cs:190. This is the fix suggested in the issue to break the GC live lock cycle by draining the finalizer queue (releasing Java proxy GRefs) before triggering a new full GC.

 if (gc >= JNIEnvInit.gref_gc_threshold) {
     Logger.Log (LogLevel.Warn, "monodroid-gc", gc + " outstanding GREFs. Performing a full GC!");
+    System.GC.WaitForPendingFinalizers ();
     System.GC.Collect ();
 }

If the PR diff appears empty on GitHub, it might be a display issue with the grafted base commit. The branch does contain the change.