[Mono.Android] reduce GC bridge and reference logging overhead

[simonrozsival]

Summary

Reduce GC bridge and GREF startup overhead that was causing significant CPU waste during app startup on CoreCLR.

Changes

• Remove WaitForGCBridgeProcessing on CoreCLR: The wait pattern is fundamentally flawed — even the Mono runtime acknowledges this with a FIXME in sgen-bridge.c: "The current usage pattern for this function is unsafe. Bridge processing could start immediately after unlock." A thread that passes the check can still race with bridge processing starting on another thread. The wait cannot prevent the race, only reduce its window. On CoreCLR, JNI wrapper threads hold their own handle copies via JniObjectReference and are not affected by the bridge swapping control_block handles. Verified with a .NET MAUI app under stress (rotation cycles, UI interaction, GC pressure) with zero crashes.

• Decouple GREF/weak-GREF counters from logging: Counter increments (_monodroid_gref_inc/_dec) and log calls (_monodroid_gref_log_new/_delete) are now independent — counters always run, logging is conditional. No more if (logging) { log_which_also_counts(); } else { count_only(); } branching.

• Trim-aware feature switch: Add Microsoft.Android.Runtime.RuntimeFeature.ObjectReferenceLogging (controlled by MSBuild property AndroidEnableObjectReferenceLogging, defaulted to false) so the linker can eliminate the entire logging code path including stack trace capture.

• Lightweight counter P/Invokes: The non-logging GREF/weak-GREF path uses cheap atomic counter entrypoints instead of the heavy logging-oriented native exports.

Startup trace comparison

Traces collected with dotnet-trace on a .NET MAUI app (TestDummy) running on an Android emulator, compared with dotnet-trace report topN --number 20.

Exclusive time — Before

#	Method	Inclusive	Exclusive
1	Interop+Sys.LowLevelMonitor_TimedWait	44.81%	44.81%
2	LowLevelMonitor.WaitCore()	26.24%	26.24%
3	IL_STUB_PInvoke (interop stub)	14.25%	14.25%
4	GC.RunFinalizers()	6.54%	6.54%
5	RuntimeNativeMethods._monodroid_gref_log_delete	5.30%	5.30%

The top 5 methods account for 97.14% of all exclusive CPU time. All five are GC bridge wait / GREF logging overhead.

Exclusive time — After

#	Method	Inclusive	Exclusive
1	JniEnvironment.CallNonvirtualBooleanMethod	5.60%	5.60%
2	JniEnvironment.CallStaticObjectMethod	6.32%	5.42%
3	GenericsHelpers.ClassWithSlotAndModule	4.56%	4.56%
4	JniEnvironment.CallObjectMethod	4.45%	4.45%
5	ContextExtensions.GetWindow	3.63%	3.63%

After the fix, the profile reflects actual app work (JNI calls, type resolution, view inflation). None of the original top-5 offenders appear anywhere in the top 100.

Testing

• dotnet build src/Mono.Android/Mono.Android.csproj -v minimal -p:AndroidApiLevel=35
• dotnet build src/native/native-clr.csproj -v minimal -p:AndroidSupportedTargetJitAbi=arm64-v8a
• dotnet build src/native/native-mono.csproj -v minimal -p:AndroidSupportedTargetJitAbi=arm64-v8a
• dotnet test tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests (323 passed)
• dotnet test tests/Microsoft.Android.Sdk.TrimmableTypeMap.IntegrationTests (10 passed)
• MAUI app stress test on emulator (10 rotation cycles, UI interaction) — zero crashes

Fixes #11104

[Copilot]

Pull request overview

This PR reduces .NET for Android startup overhead by avoiding expensive synchronization and logging work on hot JNI/GC-bridge paths, and by routing non-logging reference tracking through lightweight native counter entrypoints. It also introduces a trim-aware feature switch to disable object-reference logging by default for trimmed apps.

Changes:

• Added an idle fast-path for GC bridge waits on CoreCLR (avoids semaphore waits on common JNI transitions).
• Introduced lightweight native _monodroid_{gref,weak_gref}_{inc,dec} entrypoints and updated runtime/native code paths to use them when reference logging is disabled.
• Added RuntimeFeature.ObjectReferenceLogging and MSBuild/runtimeconfig wiring, defaulting it off for PublishTrimmed=true, plus test coverage for the new behavior.

Reviewed changes

Copilot reviewed 26 out of 26 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tests/Mono.Android-Tests/Mono.Android-Tests/System/AppContextTests.cs	Verifies the new RuntimeFeature.ObjectReferenceLogging switch value via reflection.
tests/Mono.Android-Tests/Mono.Android-Tests/Mono.Android.NET-Tests.csproj	Forces AndroidEnableObjectReferenceLogging=false for the test app to validate runtimeconfig behavior.
tests/Mono.Android-Tests/Mono.Android-Tests/Java.Interop/JnienvTest.cs	Adds CoreCLR GC-bridge wait fast-path tests (idle and active cases).
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.RuntimeConfig.targets	Adds trim-aware default and runtimeconfig option for ObjectReferenceLogging.
src/Mono.Android/Microsoft.Android.Runtime/RuntimeFeature.cs	Introduces the ObjectReferenceLogging feature switch.
src/Mono.Android/Microsoft.Android.Runtime/JavaMarshalValueManager.cs	Adds bridgeProcessingActive + WaitIfBridgeProcessing() idle fast-path and minor queue fast-path.
src/Mono.Android/Android.Runtime/AndroidRuntimeInternal.cs	Centralizes bridge-processing wait logic with runtime-specific fast-paths.
src/Mono.Android/Android.Runtime/JNIEnv.cs / JNINativeWrapper.g.*	Routes bridge wait calls through AndroidRuntimeInternal.WaitForBridgeProcessing().
src/Mono.Android/Android.Runtime/Logger.cs	Gates gref/lref logging on the new RuntimeFeature.ObjectReferenceLogging switch.
src/Mono.Android/Android.Runtime/AndroidRuntime.cs	Uses new inc/dec native counters when logging is disabled; isolates expensive stacktrace capture behind non-inlined helpers.
src/Mono.Android/Android.Runtime/RuntimeNativeMethods.cs	Adds P/Invoke declarations for _monodroid_{gref,weak_gref}_{inc,dec}.
src/native/* (mono + clr)	Adds weak-gref inc/dec implementations and updates internal pinvoke tables/generators to export the new entrypoints.

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 AI Review Summary

Verdict: ✅ LGTM

Found 0 errors, 0 warnings, 4 suggestions

Analysis

This is a well-structured performance optimization that cleanly separates GREF/WREF counter management from diagnostic logging:

• Counter decoupling — The new _monodroid_{gref,weak_gref}_{inc,dec} P/Invokes run unconditionally (cheap atomic ops), while the logging code path is gated behind RuntimeFeature.ObjectReferenceLogging. This ensures counters stay accurate regardless of logging state, while eliminating the heavy logging overhead in the common case.

• Trim-aware feature switch — The [FeatureSwitchDefinition] + RuntimeHostConfigurationOption with Trim="true" pattern is the correct approach for enabling the trimmer to dead-code-eliminate the entire logging code path (including StackTrace capture). The switch name, MSBuild key, and AppContext key are all consistent.

• WaitForGCBridgeProcessing removal (CoreCLR) — The detailed comment explaining why this is safe is excellent. The semaphore-based wait pattern was indeed a window-narrowing optimization at best, not a correctness guarantee.

• Mono/CLR parity — Both runtimes are updated consistently — same counter APIs, same log-guarding pattern, same function signature changes.

Suggestions

• 💡 Unused using System.Reflection; in JnienvTest.cs (likely leftover from an earlier iteration).
• 💡 Minor MSBuild XML indentation inconsistency ( /> vs />).
• 💡 ReleaseLocalReference count fix (localReferenceCount-1 → localReferenceCount) — this is actually a bug fix since base.ReleaseLocalReference already decremented the counter.
• 💡 Native log functions now read gc_gref_count directly instead of from the atomic increment return value, which is a benign diagnostic logging trade-off.

👍 The startup trace data is compelling — eliminating WaitForGCBridgeProcessing and GREF logging from the top-5 CPU consumers is a significant win. The native changes are clean, symmetric across both runtimes, and the new test coverage for the feature switch is appropriate.

CI: Both public checks (license/cla, dotnet-android) are ✅ passing.

---

Review generated by android-reviewer from review guidelines.

Generated by Android PR Reviewer for issue #11119 · ● 7.6M

[github-actions]

🤖 💡 Bug fix (positive) — Nice catch: the old code logged localReferenceCount - 1 here, but base.ReleaseLocalReference (called on line 173) already decrements localReferenceCount via the ref parameter. The old code was therefore logging a count that was one too low. Using localReferenceCount directly (already decremented by the base) is correct.

This is consistent with DeleteLocalReference above, which correctly uses localReferenceCount - 1 because the base hasn't been called yet at that point.

[simonrozsival]

[Copilot] Thanks for the positive note! Correct — base.ReleaseLocalReference already decrements localReferenceCount via the ref parameter, so the old localReferenceCount - 1 was double-counting the decrement. The current code correctly logs localReferenceCount directly after the base call.

[github-actions]

🤖 💡 Code organization — This using System.Reflection; directive appears unused — no types from System.Reflection (BindingFlags, MethodInfo, PropertyInfo, etc.) are referenced anywhere in this file. Likely a leftover from an earlier iteration. Consider removing it.

Rule: Remove unused code (Postmortem #58)

[simonrozsival]

[Copilot] Good catch — removed the unused using System.Reflection; directive.

[github-actions]

🤖 💡 Formatting — This closing /> has 5 spaces of indentation instead of 4, which is inconsistent with the other self-closing tags in this file (e.g., line 46, line 65).

Suggested change

	/>
	/>

Rule: XML indentation consistency

[simonrozsival]

[Copilot] Fixed — aligned the closing /> to 4 spaces to match the rest of the file.

[github-actions]

🤖 💡 Performance — Minor observation: gc_gref_count is now read directly (plain load) rather than using the atomic return value from _monodroid_gref_inc(). Between the caller's _monodroid_gref_inc() and this read, another thread could modify the counter, so the logged value may differ from the actual count at the time of this specific increment.

This is perfectly fine for diagnostic logging — the intent is showing approximate state, not an exact snapshot. Just noting this is a deliberate trade-off of the decoupling, in case someone sees log output that doesn't look sequential.

[jonathanpeppers]

This is a good point, we lost some synchronization here between the increment/decrement.

I don't actually know, but is there some C/C++ equivalent of Interlocked we could use here that would just make the number that gets logged slightly more reliable?

[simonrozsival]

[Copilot] Good point! The code already uses __sync_add_and_fetch / __sync_sub_and_fetch (GCC atomic builtins, equivalent to Interlocked.Increment/Decrement in C#) for the counter operations. The issue was that we were discarding the return value and reading gc_gref_count directly in the log functions.

Fixed by capturing the atomic return values from _monodroid_gref_inc()/_monodroid_gref_dec() etc., and passing them as grefc/gwrefc parameters to the log functions. This ensures the logged counts exactly match the state at the time of the atomic operation, with no window for another thread to modify the counter in between.