Frequent explicit Java GC during scrolling when using NativeAOT

[vyacheslav-volkov]

Android framework version

net10.0-android

Affected platform version

NET 10.0

Description

I am seeing a significant difference in Java/ART GC behavior between a regular Mono-based Android build and a NativeAOT Android build.

When the application is built without NativeAOT and runs on the Mono runtime, scrolling works smoothly and explicit Java GC is rare during normal scrolling. When it does happen, it usually frees several megabytes of Java heap, so the collection appears to be justified.

However, when the same application is built with NativeAOT, scrolling causes frequent explicit Java/ART GC invocations. These collections appear to be mostly useless according to logcat output: the Java heap is around 49–50% free, only a very small amount of memory is freed, but each GC cycle still takes around 50–95ms total time.

This seems to correlate with visible micro-stutters during scrolling, especially on weaker Android devices.

During scrolling in the NativeAOT build, logcat shows repeated Explicit concurrent copying GC entries like this:

2026-06-03 11:55:00.382  6356-6404  I  Explicit concurrent copying GC freed 24767(1208KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 15MB/30MB, paused 36us,55us total 66.541ms
2026-06-03 11:55:02.971  6356-6404  I  Explicit concurrent copying GC freed 9771(532KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 15MB/30MB, paused 67us,56us total 53.427ms
2026-06-03 11:55:04.101  6356-6404  I  Explicit concurrent copying GC freed 5453(348KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 15MB/31MB, paused 29us,49us total 49.779ms
2026-06-03 11:55:05.795  6356-6404  I  Explicit concurrent copying GC freed 5715(337KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 15MB/31MB, paused 63us,54us total 62.454ms
2026-06-03 11:55:07.041  6356-6404  I  Explicit concurrent copying GC freed 7200(463KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 15MB/31MB, paused 54us,50us total 62.270ms
2026-06-03 11:55:08.949  6356-6404  I  Explicit concurrent copying GC freed 2224(254KB) AllocSpace objects, 1(20KB) LOS objects, 49% free, 15MB/31MB, paused 80us,56us total 79.183ms
2026-06-03 11:55:10.754  6356-6404  I  Explicit concurrent copying GC freed 873(144KB) AllocSpace objects, 1(20KB) LOS objects, 49% free, 15MB/31MB, paused 49us,54us total 79.568ms

The concerning part is that these are explicit Java GC calls, but they do not seem justified by memory pressure:

49–50% free
15MB / 30–31MB heap
only ~128KB–1.2MB freed per collection
total GC time around 50–95ms

Mono behavior

In the non-NativeAOT Mono build, explicit Java GC is much less frequent during the same scrolling scenario. When it happens, it frees several megabytes of memory, so it looks much more justified:

2026-06-03 12:04:50.800  28412-28412  I  Explicit concurrent copying GC freed 171675(6883KB) AllocSpace objects, 8(448KB) LOS objects, 49% free, 16MB/33MB, paused 32us,45us total 57.721ms
2026-06-03 12:06:44.926  28412-28412  I  Explicit concurrent copying GC freed 97654(4619KB) AllocSpace objects, 38(1288KB) LOS objects, 50% free, 16MB/33MB, paused 34us,42us total 53.758ms
2026-06-03 12:07:15.847  28412-28412  I  Explicit concurrent copying GC freed 138894(6556KB) AllocSpace objects, 25(612KB) LOS objects, 50% free, 17MB/34MB, paused 69us,50us total 64.408ms

So the difference is not just that NativeAOT logs explicit Java GC. The difference is that under Mono the GC is rare and frees around 5–7MB per collection, while under NativeAOT it can happen every 1–2 seconds during scrolling and often frees only a few hundred KB.

Is there any way to disable or tune this behavior?

Steps to Reproduce

1. Create or use a .NET 10 Android application with a scrollable UI, for example a RecyclerView with enough items to continuously scroll.
2. Build and run the application with and without NativeAOT.
3. Open the screen with the scrollable list and scroll for 1–2 minutes and check the difference.

[vyacheslav-volkov]

I enabled GREF logging with:

adb shell setprop debug.mono.log gref

After that, the NativeAOT build shows a repeated pattern where the finalizer thread converts GREFs to weak GREFs, an explicit Java/ART GC is triggered, and then weak GREFs are converted back to GREFs.

This looks like NativeAOT Java interop / GC bridge processing rather than normal Java heap pressure.

Observed pattern

Around each explicit Java GC, the log looks like this:

monodroid-gref  I  +w+ grefc ... gwrefc ... obj-handle .../G -> new-handle .../W from thread 'finalizer'
monodroid-gref  I  -g- grefc ... gwrefc ... handle .../G from thread 'finalizer'

I  Explicit concurrent copying GC freed ... AllocSpace objects, ... LOS objects, 49% free, 10MB/21MB, paused ... total ...

monodroid-gref  I  +g+ grefc ... gwrefc ... obj-handle .../W -> new-handle .../G from thread 'finalizer'
monodroid-gref  I  -w- grefc ... gwrefc ... handle .../W from thread 'finalizer'

So the sequence appears to be:

GREF -> weak GREF
explicit Java/ART GC
weak GREF -> GREF / weak ref cleanup

The concerning part is that this happens repeatedly during normal scrolling, even when the Java heap is not under pressure and the GC frees only a few dozen KB.

I captured a very short scroll gesture with enabled GREF logging, roughly 10–20 list items.
During this short scroll, the NativeAOT build triggered around 20 explicit Java GC cycles in roughly 2 seconds. Most of them freed only around 26KB–160KB, while the Java heap was still around 49% free.

12:56:46.515  I  Explicit concurrent copying GC freed 2213(160KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 63us,90us total 72.075ms
12:56:46.624  I  Explicit concurrent copying GC freed 378(29KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 62us,90us total 72.261ms
12:56:46.702  I  Explicit concurrent copying GC freed 76(36KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 58us,86us total 71.602ms
12:56:46.789  I  Explicit concurrent copying GC freed 30(28KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 76us,83us total 74.080ms
12:56:46.886  I  Explicit concurrent copying GC freed 104(42KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 58us,91us total 71.844ms
12:56:46.973  I  Explicit concurrent copying GC freed 36(26KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 66us,96us total 74.792ms
12:56:47.080  I  Explicit concurrent copying GC freed 215(56KB) AllocSpace objects, 1(20KB) LOS objects, 49% free, 10MB/21MB, paused 168us,92us total 80.550ms
12:56:47.166  I  Explicit concurrent copying GC freed 324(105KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 71us,92us total 74.086ms
12:56:47.184  I  Choreographer: Skipped 44 frames! The application may be doing too much work on its main thread.
12:56:47.291  I  Explicit concurrent copying GC freed 1435(65KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 73us,91us total 74.766ms
12:56:47.390  I  Explicit concurrent copying GC freed 341(28KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 166us,119us total 81.953ms
12:56:47.481  I  Explicit concurrent copying GC freed 119(30KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 69us,84us total 74.292ms
12:56:47.592  I  Explicit concurrent copying GC freed 83(35KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 99us,97us total 75.192ms
12:56:47.697  I  Explicit concurrent copying GC freed 172(60KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 67us,90us total 74.357ms
12:56:47.779  I  Explicit concurrent copying GC freed 33(35KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 60us,97us total 73.882ms
12:56:47.822  I  Choreographer: Skipped 37 frames! The application may be doing too much work on its main thread.
12:56:47.854  I  OpenGLRenderer: Davey! duration=1385ms
12:56:48.057  I  Explicit concurrent copying GC freed 876(72KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 188us,107us total 84.696ms
12:56:48.187  I  Explicit concurrent copying GC freed 451(61KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 163us,107us total 78.564ms
12:56:48.285  I  Explicit concurrent copying GC freed 11(31KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 204us,105us total 83.446ms
12:56:48.373  I  Explicit concurrent copying GC freed 9(32KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 156us,106us total 80.372ms
12:56:48.460  I  Explicit concurrent copying GC freed 9(32KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 153us,105us total 80.009ms
12:56:48.547  I  Explicit concurrent copying GC freed 4(31KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 145us,103us total 78.048ms
12:56:48.638  I  Explicit concurrent copying GC freed 9(32KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 153us,105us total 79.756ms

This is a very small amount of memory reclaimed for such frequent explicit GC calls.

Around the GC burst, monodroid-gref shows many entries like:

monodroid-gref  I  +w+ grefc 1359 gwrefc 1 obj-handle .../G -> new-handle .../W from thread 'finalizer'
monodroid-gref  I  -g- grefc 1358 gwrefc 1 handle .../G from thread 'finalizer'
...
I  Explicit concurrent copying GC freed 378(29KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 10MB/21MB, paused 62us,90us total 72.261ms
...
monodroid-gref  I  +g+ grefc 1357 gwrefc 4 obj-handle .../W -> new-handle .../G from thread 'finalizer'
monodroid-gref  I  -w- grefc 1357 gwrefc 3 handle .../W from thread 'finalizer'

The GREF count is not extremely high. In this capture it is roughly in the 1350–1420 range, so this does not look like a massive GREF leak. It looks more like the NativeAOT GC bridge is repeatedly triggering Java GC while processing a relatively small number of weak global references.

[vyacheslav-volkov]

I looked through the NativeAOT Android GC bridge code and I think the repeated Java GC calls may be caused by the way the bridge processes unreachable managed wrappers for Java peer objects.

From what I understand, when the managed GC finds Java peer objects that are no longer strongly reachable from managed code, but may still be reachable from the Java side, NativeAOT needs to resolve this cross-runtime lifetime situation.

The current flow appears to be roughly:

managed GC finds cross-runtime candidates
→ NativeAOT GC bridge receives mark_cross_references(args)
→ bridge converts relevant GREFs to weak GREFs
→ bridge explicitly calls Java Runtime.gc()
→ bridge checks which weak references survived Java GC
→ bridge converts surviving weak GREFs back to GREFs

If my understanding is correct, this means that even a small number of managed-unreachable Java peer wrappers can cause an explicit Java/ART GC. In my logs, this seems to happen repeatedly during scrolling, and many of these GC calls reclaim only a few dozen KB while the Java heap is still around 49% free.

If this interpretation is correct, maybe the bridge should have some kind of threshold or batching policy before calling Runtime.gc(), for example based on:

• number of bridge candidates / weak refs to process;
• time since the last Java GC;
• Java heap pressure;
• avoiding repeated Java GC calls for very small batches during UI activity.

I may be misunderstanding some details of the bridge implementation, but the observed pattern looks like repeated low-yield Java GC calls caused by cross-runtime peer lifetime checks rather than real memory pressure.