NativeAOT TODO list

[jonathanpeppers]

What do we need to do for NativeAOT?

Current status for .NET 11 NativeAOT.

To investigate next:

• Re-test dotnet publish; this was reported to fail while dotnet build worked during the original preview implementation
• Re-test the current dotnet new maui template with NativeAOT

List of TODOs:

• dotnet new android && dotnet publish -p:PublishAot=true
  • [nativeaot] introduce Microsoft.Android.Runtime.NativeAOT.dll #9760
• dotnet new maui runs
  • [WIP] turn NativeAOT sample into a .NET MAUI app #9747
• Parse Android system properties such as debug.mono.log, including disabling lref/gref logging
  • [Microsoft.Android.Runtime.NativeAOT] Parse debug.mono.log #9824
• Provide a printf-style alternative to monodroid_log() for NativeAOT
  • [Native] Add printf-style native logging #12140
  • Follow-up migrations: [NativeAOT] Migrate runtime utility logging to printf #12148, [CoreCLR/NativeAOT] Migrate JNI reference logging to printf #12150, [NativeAOT] Migrate shared GC logging to printf #12210, [NativeAOT] Migrate GC bridge logging to printf #12211, [NativeAOT] Add printf gref logging #12218
• MSBuild warning for non-Mono runtimes that says they are experimental
  • [Xamarin.Android.Build.Tasks] emit XA1040 for experimental runtimes #9834
• Default $(PublishAotUsingRuntimePack)=true
  • [nativeaot] default to $(PublishAotUsingRuntimePack)=true #9815
• Get Mono.Android-Tests running on NativeAOT
  • [nativeaot] run Mono.Android-Tests #9846
  • Remaining exclusions are tracked by NativeAOT on-device tests #10079
• Finish runtime/startup behavior that differs from Mono
  • System.Threading.Tasks synchronization context: [nativeaot] fix default SynchronizationContext #9883
  • NativeAOT coverage for timezone and Android uncaught-exception handling: Enable more tests to run on all 3 runtimes, part 14 #10644
  • AppDomain.CurrentDomain.UnhandledException is still explicitly skipped under NativeAOT
• Address all NativeAOT trimming and AOT warnings
  • [TrimmableTypeMap] Address all trimming and AOT warnings #10794
• Remove the TrimmerRootAssembly NativeAOT size deoptimization
  • TrimmerRootAssembly deoptimizes size of native AOT apps #10672
• Avoid dynamically linking libc++_shared.so; NativeAOT currently links libc++_static.a
• Remove the NativeAOT libc++ dependency entirely
  • [NativeAOT] Remove libc++ from libNativeAOT.so #12139
• Warn when code calls JNINativeWrapper.CreateDelegate(...)
  • The API is annotated with [RequiresDynamicCode], producing an AOT warning for callers
  • Framework usages were removed by [Mono.Android] Remove usages of JNINativeWrapper.CreateDelegate. #9741
• Decide whether NativeAOT should support FastDeploy/incremental deployment; it is currently explicitly unsupported by the test suite
• Enable $(VerifyReferenceAotCompatibility)
  • Add trim/aot analyzer warnings for transitive references runtime#118180

[jonpryor]

Alternate "MVP 1.1" typemap idea, for posterity: instead of a Dictionary<string, Type>, have two fields:

1. Dictionary<string, RuntimeTypeHandle> or string[]+RuntimeTypeHandle[] pair, plus
2. Dictionary<string, Type>

The linker step would populate (1), which might be faster because RuntimeTypeHandle is a stuct.

At runtime, consult (2) first, and if a type mapping doesn't exist, use (1) to lookup the RuntimeTypeHandle + Type.GetTypeFromHandle(RuntimeTypeHandle), caching the result in (2).

Questions:

• Can we lookup the RuntimeTypeHandle value from Cecil?
• The caching will require locking. What kind of overhead will this imply?

[jonathanpeppers]

There must be a way to use a TypeHandle with Mono.Cecil, as the IL "typemap MVP 1.0" is writing is doing this:

android/src/Microsoft.Android.Sdk.ILLink/TypeMappingStep.cs

Lines 70 to 83 in 70bd636

	/*
	* IL_0000: ldarg.0
	* IL_0001: ldfld class [System.Runtime]System.Collections.Generic.IDictionary`2<string, class [System.Runtime]System.Type> Microsoft.Android.Runtime.NativeAotTypeManager::TypeMappings
	* IL_0006: ldstr "java/lang/Object"
	* IL_000b: ldtoken [Mono.Android]Java.Lang.Object
	* IL_0010: call class [System.Runtime]System.Type [System.Runtime]System.Type::GetTypeFromHandle(valuetype [System.Runtime]System.RuntimeTypeHandle)
	* IL_0015: callvirt instance void class [System.Runtime]System.Collections.Generic.IDictionary`2<string, class [System.Runtime]System.Type>::Add(!0, !1)
	*/
	il.Emit (Mono.Cecil.Cil.OpCodes.Ldarg_0);
	il.Emit (Mono.Cecil.Cil.OpCodes.Ldfld, field);
	il.Emit (Mono.Cecil.Cil.OpCodes.Ldstr, javaKey);
	il.Emit (Mono.Cecil.Cil.OpCodes.Ldtoken, module.ImportReference (typeDefinition));
	il.Emit (Mono.Cecil.Cil.OpCodes.Call, getTypeFromHandle);
	il.Emit (Mono.Cecil.Cil.OpCodes.Callvirt, addMethod);

[filipnavara]

Ldtoken returns RuntimeTypeHandle so you can use that in the dictionary. It's, however, not a pattern that can be represented in C# and ILSpy will not decode it correctly.

[simonrozsival]

I'm currently exploring this direction for the type map: https://gist.github.com/simonrozsival/8b3f2294d7fa1cf84ca32e8145984c98

• there's no startup initialization - the Java class name hashes are stored in a sorted array that's baked into the assembly
• the runtime type handles are stored in code and are accessed via a jumptable (switch) - this allows us to "serialize" RuntimeTypeHandles in a way which Native AOT understands

What do you think?

[jonathanpeppers]

@simonrozsival brought up a point that the RuntimeTypeHandle values might not match up at runtime in NativeAOT:

• We run ILLink
• At some point during/after ILLink, we generate a managed typemap, if we used RuntimeTypeHandle...
• ILC runs and uses its own set of integers (who knows?) instead of RuntimeTypeHandle

[simonrozsival]

ILC runs and uses its own set of integers (who knows?) instead of RuntimeTypeHandle

I don't think I expressed myself correctly. If we generate IL that builds the Dictionary<string, RuntimeTypeHandle> using il.Emit (Mono.Cecil.Cil.OpCodes.Ldtoken, module.ImportReference (typeDefinition));, then Native AOT will compile this correctly. That's not the problem.

I was trying to say that we cannot serialize the raw numeric values of RuntimeTypeHandle while we're processing the IL and use it for lookups via Type.GetTypeFromHandle at runtime.

We can of course create an array of RTH, but it will need to be initialized at startup:

static readonly RuntimeTypeHandle[] s_handles = [ typeof(X).TypeHandle, typeof(Y).TypeHandle ];

// is compiled to IL like this:
.method private hidebysig specialname rtspecialname static 
    void .cctor () cil managed 
{
    // Method begins at RVA 0x2058
    // Code size 56 (0x38)
    .maxstack 8

    IL_0000: ldc.i4.2
    IL_0001: newarr [System.Runtime]System.RuntimeTypeHandle
    IL_0006: dup
    IL_0007: ldc.i4.0
    IL_0008: ldtoken X
    IL_000d: call class [System.Runtime]System.Type [System.Runtime]System.Type::GetTypeFromHandle(valuetype [System.Runtime]System.RuntimeTypeHandle)
    IL_0012: callvirt instance valuetype [System.Runtime]System.RuntimeTypeHandle [System.Runtime]System.Type::get_TypeHandle()
    IL_0017: stelem [System.Runtime]System.RuntimeTypeHandle
    IL_001c: dup
    IL_001d: ldc.i4.1
    IL_001e: ldtoken Y
    IL_0023: call class [System.Runtime]System.Type [System.Runtime]System.Type::GetTypeFromHandle(valuetype [System.Runtime]System.RuntimeTypeHandle)
    IL_0028: callvirt instance valuetype [System.Runtime]System.RuntimeTypeHandle [System.Runtime]System.Type::get_TypeHandle()
    IL_002d: stelem [System.Runtime]System.RuntimeTypeHandle
    IL_0032: stsfld valuetype [System.Runtime]System.RuntimeTypeHandle[] X::s_handles
    IL_0037: ret
} // end of method X::.cctor

[filipnavara]

We can of course create an array of RTH, but it will need to be initialized at startup:

ILC can interpret some static constructors at compile time and produce preinitialized data in the executable image. It would not work for the Dictionary but it can probably work for a simple array... (or can be tweaked to work if it doesn't at the moment)