Skip to content

Comments

[WIP] Fix GC live lock issue in rapid UI switching#10856

Draft
Copilot wants to merge 1 commit intomainfrom
copilot/fix-gc-live-lock-issue-again
Draft

[WIP] Fix GC live lock issue in rapid UI switching#10856
Copilot wants to merge 1 commit intomainfrom
copilot/fix-gc-live-lock-issue-again

Conversation

Copy link
Contributor

Copilot AI commented Feb 24, 2026

Thanks for assigning this issue to me. I'm starting to work on it and will keep this PR's description up to date as I form a plan and make progress.

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:

Relevant log output

```</issue_description>

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

<comments>
</comments>

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GC live lock

2 participants