Figure out Debug build configuration for R2R

[BrzVlad]

Context

#24437 (#24725) Added support for R2R which, on debug builds, does a compilation of all assemblies except user assemblies (these are considered assemblies that don't have a NuGet package id)

#25583 We r2r only SPC.dll due to excessive size

#25787 Above change had to be reverted due to x64 issues, enabled only on arm64 builds now.

Bug

For whatever reason, during the revert, this exposed a problem with the original filtering of assemblies. Normally, a composite r2r compilation receives the full set of app assemblies (this is a self contained only mode) and compiles everything. Doing an incomplete r2r compilation like we do on debug build is non standard and we are not even passing the user assemblies as a reference. This can lead to r2r tripping up when trying to load some types (only when using ReadyToRunVisibilityRootProvider). Reproduced this standalone in https://github.com/BrzVlad/repros/tree/main/maui-debug-r2r.

With the partial revert, this bug would exist only on x64 builds

Future Debug build configuration

I believe we can do better than using r2r only for SPC.dll. On android we have some infrastructure for building a profile to be passed to r2r. I believe we can do the same for iOS Debug builds, so we can obtain even better performance at the cost of minimal size increase.

Work items

• Setup infrastructure to obtain a profile from a MAUI iOS app. Rather than only getting a startup profile, we would probably want to automate the app to navigate through various common controls so we get a larger profile
• Improve flexibility for r2r. I believe the configuration we are aiming for is to pass all assemblies to the composite r2r mode, use partial mode so that we only r2r methods from the profile, but we would also want to ensure that everything from SPC.dll is still compiled (this goes against the current partial mode, we would need to add a new flag to root SPC.dll)
• Make the build use this mode instead. This would also fix any potential r2r referencing issues like the one from the linked repro.

[BrzVlad]

Was looking the other day into a maui build regression and wrote this down so the investigation is not lost. This can also serve as planning on whether we agree to move with a profiled AOT solution for debug builds, which would also fix the problem. cc @vitek-karas @kotlarmilos @davidnguyen-tech

@rolfbjarne I haven't tested but I would assume the repro in question would fail currently on x64. In that case we might want to fix it separately for now. I believe the simplest fix would be to pass all user assemblies as --reference to crossgen2, rather than just ignore them.

[vitek-karas]

Using profile based partial R2R for debug builds sounds like a good idea, I'm a bit worried about the complexity. Not trying to shoot this down, just pointing out things we would have to consider:

• dotnet/optimization repo doesn't have the ability to run anything on mac right now, to produce a good profile we would need to run at least a simulator app.
• partial R2R combined with debugger -> some methods can be stepped into, while others can't. And the behavior is largely unpredictable and likely to change with each rebuild of the profile (so previews, releases).

[BrzVlad]

dotnet/optimization repo doesn't have the ability to run anything on mac right now, to produce a good profile we would need to run at least a simulator app.

Yeah, the infra to obtain the profile seems like the most painful bit, given that we are not allowed do use a manually obtained profile. I know @davidnguyen-tech was playing in the area so I was counting on him for an opinion :D.

partial R2R combined with debugger -> some methods can be stepped into, while others can't. And the behavior is largely unpredictable and likely to change with each rebuild of the profile (so previews, releases).

I don't see why this would be the case. The profile would only obtain methods from the framework, that wouldn't be debuggable anyway. So I don't believe you would be able to step into them regardless of whether they are interpreted or r2r. I believe debugging works only in JustMyCode mode anyway for mobile.

[vitek-karas]

I believe debugging works only in JustMyCode mode anyway for mobile.

It's true that this is the default (I think). For most users this would be a non-issue. Good point.

[davidnguyen-tech]

On android we have some infrastructure for building a profile to be passed to r2r. I believe we can do the same for iOS Debug builds, so we can obtain even better performance at the cost of minimal size increase.

Note that in the .nettraces, we've observed that some framework methods have an app-specific prefix, which makes them appear as if they were user-written methods. For that reason, those framework methods aren't AOT-compiled by R2R in practice.

I believe the configuration we are aiming for is to pass all assemblies to the composite r2r mode, use partial mode so that we only r2r methods from the profile, but we would also want to ensure that everything from SPC.dll is still compiled (this goes against the current partial mode, we would need to add a new flag to root SPC.dll)

If we pass .mibc profiles to Full R2R, crossgen roots the methods from the profile as well. Maybe we could use SPC-only Full R2R + .mibc profile for simplicity here?

dotnet/optimization repo doesn't have the ability to run anything on mac right now, to produce a good profile we would need to run at least a simulator app.

Yeah, the infra to obtain the profile seems like the most painful bit, given that we are not allowed do use a manually obtained profile.

Collecting a profile on an iOS simulator sounds doable to me - we have the main pieces already:

• there is a macOS machine in dotnet/optimization CI
• the collecting logic should be similar to Android

I think we should get some performance data first, before we invest more into this approach :)

I believe debugging works only in JustMyCode mode anyway for mobile.

It's true that this is the default (I think). For most users this would be a non-issue. Good point.

From what I've tested recently, I can confirm that JustMyCode is the default.

[BrzVlad]

If we pass .mibc profiles to Full R2R, crossgen roots the methods from the profile as well. Maybe we could use SPC-only Full R2R + .mibc profile for simplicity here?

This is what I was suggesting but I'm not sure if it works out of the box. Rough high level idea of the r2r commands, they might be slightly imprecise:

• crossgen *.dll -mibc profile.mibc is full r2r with additional methods from the profile. -> too much for debug
• crossgen *.dll -mibc profile.mibc -partial r2r only the methods from the profile. -> missing SPC.dll
• crossgen SPC.dll -mibc profile.mibc. You suggest it might work. Not clear if included profile methods from an assembly you are not rooting just works. We should test this.

[kotlarmilos]

@BrzVlad good idea. The repro would fail on x64 today, and with #25876 re-enabling the SPC-only composite root on x64 the issue gets masked there as well. But it's still a latent bug in the partial composite path, so we should fix it properly regardless. Passing all user assemblies as --reference to crossgen2 instead of dropping them sounds like the right minimal fix

On the longer term, the profiled partial R2R direction with prelminary perf improvements sounds good to me.

[kotlarmilos]

Created a PR to pass all user assemblies as references to crossgen2: #25879