[CoreCLR] Enable cached ReadyToRun for Android Debug builds

[kotlarmilos]

Summary

CoreCLR Android Debug builds currently use JIT compilation for all assemblies. Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including System.Private.CoreLib.dll, to improve startup performance while keeping user assemblies as IL for normal debugging and incremental development.

Android Debug application size is not a primary constraint. The ReadyToRun output should be generated once for each RID and stable framework input set, then reused by subsequent builds. Changes limited to user assemblies must not rerun crossgen2.

This issue covers non-profiled Debug ReadyToRun.

Tasks

• Define the framework and SDK assembly set, including System.Private.CoreLib.dll
• Enable ReadyToRun by default for CoreCLR Debug builds
• Keep user assemblies out of ReadyToRun compilation
• Cache ReadyToRun output by RID and framework inputs
• Ensure user-code changes do not invalidate the ReadyToRun cache
• Integrate the output with fast deployment

[jonathanpeppers]

Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including System.Private.CoreLib.dll

Can we do this ahead of time? And the image is just inside the runtime pack?

If I look at System.Private.CoreLib.dll on my Windows machine, it has a win-x64 R2R image inside already:

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\<version>\System.Private.CoreLib.dll

If I were to set this up for Mono.Android.dll or Java.Interop.dll, I would also do it ahead of time inside the runtime pack.

[kotlarmilos]

Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including System.Private.CoreLib.dll

Can we do this ahead of time? And the image is just inside the runtime pack?

If I look at System.Private.CoreLib.dll on my Windows machine, it has a win-x64 R2R image inside already:

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\<version>\System.Private.CoreLib.dll

If I were to set this up for Mono.Android.dll or Java.Interop.dll, I would also do it ahead of time inside the runtime pack.

We can generate them ahead of time, but those images only work with the full untrimmed assemblies. Do we run trimming on these assemblies in Debug?

[jonathanpeppers]

Do we run trimming on these assemblies in Debug?

No, Android doesn't have a need to trim in debug mode.

Someone, could turn on PublishTrimmed=true in debug mode, but I wouldn't recommend as it would make your incremental builds slower.

[kotlarmilos]

I measured this end to end on net11 CoreCLR for android-arm64, comparing the current Debug default against the framework-R2R approach in #12118, on both a hello-world app and a MAUI app, which R2Rs the runtime pack assemblies including Mono.Android.dll and excludes user code.

Hello-world, no measurable difference. Startup is dominated by runtime init rather than managed JIT, so R2R does not improve it. MAUI framework R2R is consistently about 100ms or 3% faster than JIT and about 6MB bigger app with a first clean crossgen2 pass about 20s, with incremental builds reusing the crossgen cache.

Based on this, trimming in Debug regresses the inner dev loop, and adding R2R back on trimmed assemblies is not a good fit here. It could make sense to ship pre-compiled Mono.Android.dll or Java.Interop.dll to gain 3% faster startup (not complete inner dev loop) at the cost of a 6 MB larger app. Worth confirming with few customer apps before dedicating the effort.