Android: Debug Mode & Interpreter Performance

[jonathanpeppers]

Description

I'm investigating an app that is very slow in Debug mode:

• Loading Android Apps on the debugger is way too slow maui#23991
• https://github.com/chabiss/periodictable

Note that Debug mode on Android:

• Uses interpreter for C# hot reload
• No trimmer, no AOT
• No XAML compilation, so XAML is parsed
• $(Optimize) C# compiler setting, etc.

Those are a lot of reasons this is generally, slower.

I think I narrowed down to a basic Java interop method that showcases one slowdown under interp:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal unsafe static void DeleteLocalRef(nint env, nint instance)
{
    (*(JNIEnv**)env)->DeleteLocalRef(env, instance);
}

// Then the C# function pointer is
internal struct JNIEnv
{
    public unsafe delegate* unmanaged<nint, nint, void> DeleteLocalRef;
}

Using our latest stable releases, you can see this method:

Debug:
1.09s (3.0%) java.interop!Java.Interop.JniEnvironment.References.DeleteLocalRef(intptr)
Release:
274.47ms (1.0%) java.interop!Java.Interop.JniEnvironment.References.DeleteLocalRef(intptr)

(Note that I compared the calling method, because of aggressive inlining)

DeleteLocalRef() is just one instance of a slow method under interp, general Java interop will invoke many other methods like this.

Other ideas:

• Is there a way we could try to JIT some assemblies and use interp for the rest? If we used JIT for Mono.Android.dll and Java.Interop.dll those would never be C# "hot reloaded".

Reproduction Steps

Debug the sample in VS on Android:

• https://github.com/chabiss/periodictable

Expected behavior

Performance of (*(JNIEnv**)env)->DeleteLocalRef(env, instance) is reasonable in Debug mode.

Actual behavior

Performance of (*(JNIEnv**)env)->DeleteLocalRef(env, instance) could be improved.

Regression?

No, I think this was always the case.

Known Workarounds

Disable the interpreter with UseInterpreter=false, or run Release mode.

Configuration

dotnet --version
8.0.400

Other information

Here are some dotnet-trace's I've recorded of this app: debug_vs_release.zip

[dotnet-policy-service]

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

[BrzVlad]

It is not clear to me from the report, but is the performance with interpreter acceptable in release mode ? I don't think it would be a good ideea to start mixing with aot/jit code, but I think it is feasible to support hotreload/debug in the user assemblies only and have the sdk/runtime assemblies always fully optimized.

[jonathanpeppers]

Will everything work if we built libaot-Mono.Android.dll.so / libaot-Java.Interop.dll.so, and tried to use these in Debug mode? We would probably try MONO_AOT_MODE_NORMAL initially.

The only concern is what happens if runtime has a 9.0.1 service release, for example? We don't necessarily release a new Android workload at the same time. So, would an older AOT image always work with newer runtimes?

[BrzVlad]

Will everything work if we built libaot-Mono.Android.dll.so / libaot-Java.Interop.dll.so, and tried to use these in Debug mode? We would probably try MONO_AOT_MODE_NORMAL initially.

Interpreter fallback currently only works in aot only scenario. We never ran aot-only on android. It is definitely logically possible but it is not trivial and it represents a new configuration to maintain that doesn't seem to have significant justification in my opinion.

The only concern is what happens if runtime has a 9.0.1 service release, for example? We don't necessarily release a new Android workload at the same time. So, would an older AOT image always work with newer runtimes?

My understanding is that the android workload holds the versions for both the device runtime as well as for the aot cross compiler and it doesn't matter if the version is different from the desktop runtime. There can be problems if the version that is used to aot compile is different from the version at runtime.

[jonathanpeppers]

There can be problems if the version that is used to aot compile is different from the version at runtime.

Yes, I think this is what would happen. Each time a new runtime is serviced, we don't necessarily ship a new Android workload. You would get new Mono packages like the AOT compiler, runtime packs, etc.

[vitek-karas]

I don't think we will do this - I hope you agree @jonathanpeppers .