[Android] Periodic frame rate drops (60→54 FPS; 6-10 consecutive frames c. every 5 seconds) with CoreCLR on .NET 11 — regression from Mono on .NET 10

[janne-hmp]

Description

We are developing a real-time roguelike game (GnollHack) using .NET MAUI with SkiaSharp (SKGLView) for rendering on Android. The game targets 60 FPS and achieves this consistently on .NET 10 with the Mono runtime.

As per the post by @davidortinau last week, we tested .NET MAUI 11 Preview 6 on Android to see how it compares with Mono Runtime in .NET 10. After upgrading to .NET 11 Preview 6+ (which uses CoreCLR exclusively on Android), we observe periodic (every 5 seconds or so) frame rate drops from 60 FPS to approximately 50–54 FPS (6-10 consecutive frames drop every 5 seconds or so), causing severe stutters in the game and making the game to feel continuously very jerky. These drops occur at regular intervals regardless of scene complexity, even on screens with very little drawing. The drops are clearly visible as jerkiness/microstutters during gameplay.

This appears to be a performance regression introduced by the Mono → CoreCLR transition on Android.

If @jfversluis or @jonathanpeppers or someone else already know a solution working for this in .NET MAUI 11, please let me know.

Expected Behavior

Consistent 60 FPS rendering, matching .NET 10 (Mono) performance.

Actual Behavior

Frame rate periodically drops to 50–54 FPS at regular intervals, causing visible jerkiness. The drops occur:

• From the very start of the application
• Regardless of scene complexity (even with minimal drawing)
• At consistent, periodic intervals

Attempted Mitigations (none helped)

Setting	Result
DOTNET_TieredCompilation=0	No improvement
DOTNET_GCGen0MaxBudget=8000000 (128 MB)	No improvement
DOTNET_gcServer=0 (Workstation GC)	No improvement
Default CoreCLR settings (no tuning)	Same periodic drops

Steps to Reproduce

1. Create a .NET MAUI application targeting net11.0-android with a SkiaSharp SKGLView rendering at 60 FPS.
2. Build and deploy to an Android device.
3. Observe periodic frame rate drops from 60 to ~54 FPS at regular intervals.
4. Compare with the same application targeting net10.0-android (Mono runtime) — no such drops occur.

Environment

• .NET SDK: 11.0.100-preview.6 (or later)
• Runtime: CoreCLR (Mono no longer available in Preview 6+)
• Platform: Android (arm64)
• Rendering: SkiaSharp SKGLView (OpenGL ES)
• Target FPS: 60
• Device: (Insert your test device and Android version here)
• Comparison baseline: .NET 10 with Mono runtime — consistent 60 FPS, no drops

Additional Context

• The application is a complex roguelike game with native C libraries linked via P/Invoke, FMOD audio, and multi-layer tile rendering.
• The frame drops are not correlated with scene complexity, suggesting the cause is runtime-level periodic work (GC, thread pool, diagnostics, or other background activity) rather than application code.
• We also encountered a separate issue where DOTNET_DiagnosticPorts in Environment.txt (previously used for Mono debugging) caused the CoreCLR runtime to suspend at startup and never resume. Removing it fixed that issue, but the periodic FPS drops remain.
• <UseMonoRuntime>true</UseMonoRuntime> is no longer supported in .NET 11 Preview 6+, so we cannot fall back to Mono to verify the regression on the same SDK version.

[janne-hmp]

I made a test app to show the periodic drop in FPS: https://github.com/hyvanmielenpelit/Net11FPSBenchmark Here it happens, every 10 to 20 s or so. It has various extra switches to test things, and also the iOS issue separately, but it currently best works for demonstrating this problem on Android. There is also a script to alternate between .NET 10 and .NET 11. In .NET 10 you can observe a much smoother FPS behavior.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[steveisok]

Could be something in the GC bridge. dotnet/android#11567 seems to be showing something similar.

[steveisok]

Important

Corrected 2026-08-10. Two claims below were wrong and are struck through in place.

1. WeakReference.Target bridge blocking is a contributor — it is worth ~41% of the lost
   frame time. My original experiment used a strong-reference arm as a control, but that was not a
   control: dotnet/android resolves peers through weak references on the UI thread irrespective of
   what the probe reads, so both arms already contained the mechanism. Symbolized off-CPU profiling
   puts GCHandle_InternalGetBridgeWait → WaitForGCBridgeFinish at 31.34% of UI-thread
   off-CPU time with peers and absent without them, with the probe's own read loop off (reads=0).
   Reduce weak ref blocking with java interop #131952 addresses this.
2. Throttling the request does not work — measured neutral at 50 ms and actively harmful at
   200 ms, because bridge objects are force-promoted whether or not the request is sent, so
   skipping it buys nothing and lets more of them accumulate.

Suggested fix #1 (skip the SCC pass when the client is busy) still holds.

I was curious so I did some analysis:

Reproduced with a small Android probe: a frame-pacing harness that runs two modes allocating the same number of objects and bytes each frame. The only difference is that one mode gives each object a Java peer and the other doesn't. The no-peer mode is the control — if frames drop there too, the cause is allocation, not the bridge.

Mechanism. When a .NET object is paired with a Java object, neither runtime can free its side alone — they have to compare notes. So whenever a .NET GC finds even one such pair where the .NET side is dead, it asks Android to run a Java GC to check whether the Java side is dead too. That request is unthrottled, so a gen0 collection is enough to trigger a full ART collection.

The problem isn't the ART collection itself — it's what it does to the UI thread. Drawing a frame creates Java objects, and creating one takes a lock that the running ART collection holds for long stretches. So the UI thread sleeps ~15 ms at a time and misses its frame deadline.

Perfetto and simpleperf confirm each step: every stall (60/60) lands inside an ART collection; the same managed work costs 39.4 ms during one vs 1.30 ms outside (~30×); and 80.6% of the UI thread's waiting is in art::JavaVMExt::AddGlobalRef — the lock in question. The control mode shows none of this, so it's the bridge, not the allocation.

Correction: the 80.6% figure came from an unsymbolized profile and misattributes the cost. With
symbols, the block is in libcoreclr, not libart — AddGlobalRef is CPU spin worth 2.67%, while
WaitForGCBridgeFinish is 31.34% of UI-thread off-CPU time. The conclusion that it's the bridge
rather than the allocation is unaffected.

On the regression framing. Mono also drops frames (60 → ~57). It fires ~2× more explicit GCs (396 vs 212) yet loses ~4× less time (283 ms vs 1175 ms per 5 s) — so per-event cost dominates, not trigger frequency.

Suggested fixes — runtime side.

1. Skip the Tarjan/SCC pass when the client is still processing a previous set — the VM already discards those args, so the work is wasted. Behavior-neutral.
2. Throttle how often new requests are produced (e.g. System.GC.BridgeMinIntervalMs, default 50 ms), gen0 only — bridge objects are force-promoted regardless, so leaving gen1+ unthrottled bounds retention to the next gen1 GC. Withdrawn — measured neutral at 50 ms and harmful at 200 ms, for exactly the reason the strikethrough text concedes: the objects are promoted whether or not the request is sent.
3. Make the weak-reference wait precise, so a read only blocks when its own target is in the in-flight request. Worth ~41% of the lost frame time; see Reduce weak ref blocking with java interop #131952.

Suggested fix — dotnet/android side. GCBridge::trigger_java_gc calls Runtime.gc() unconditionally on every bridge request, with no rate limiting or coalescing. Since the request is advisory, a minimum interval or a "skip if a collection just ran" check there would cut trigger rate independently of the runtime change — and it's the layer that can see how recently ART actually collected. Worth considering whether every request needs a full explicit collection at all.

The larger remaining share is the force-promotion itself: every dead bridge object is copied out of gen0 on every collection, which is worth ~59% of the lost frame time and is not addressed by any of the above.

Numbers are from an emulator (understates cost); any throttle default would need tuning on real arm64.

Ruled out: debug.mono.log=gc,gref fabricates this bug via logcat volume — don't measure with it on.

Probe, prototypes and raw runs: https://github.com/steveisok/android-gcbridge-investigation

Note

This analysis was generated with GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.