[NativeAOT] Improve managed typemap

[simonrozsival]

This is a follow-up to #9856

#9846 showed that several tests are failing with the new managed type map. This PR addresses two of these issues:

1. Use assembly qualified type name instead of just full name for the Managed -> Java mapping
2. Generic types are handled correctly:
   • for managed -> java mapping, include all the different types which map to the same java class name (e.g., JavaList and JavaList<object> both map to java/util/ArrayList)
   • for java -> managed mapping, prefer non-generic base classes over generic subclasses (e.g., map java/util/ArrayList to JavaList instead of JavaList<>)

These changes now break roundtripping (JavaList<T> -> java/util/ArrayList -> JavaList). I implemented a new way of ensuring there isn't a runtime hash collision.

[jonathanpeppers]

The APK tests that failed are networking related:

System.AggregateException : AggregateException_ctor_DefaultMessage (Ignoring network/server failure: ServiceUnavailable)
----> NUnit.Framework.IgnoreException : Ignoring network/server failure: ServiceUnavailable

They are also running on Mono, so shouldn't be using this NativeAOT code path anyway.

[jonpryor]

Draft commit message:

Context: https://github.com/dotnet/android/pull/9846
Context: efbec22767427f5704b6b20b3b36ff6c3c7067f2
Context: https://github.com/dotnet/android/issues/2266
Context: 684ede6a79da5b95eb9347c319683d8855f84d09
Context: https://github.com/xamarin/monodroid/commit/eb04c91c3f202d369c8a2930462ebff4f48b2e3e
Context: https://github.com/dotnet/java-interop/commit/397013edb915d7d3afc876993c502369de1ec015

`Java.Interop.JniRuntime.JniTypeManager` supports bi-directional
mapping between JNI type signatures and managed `Type`s:

  * `GetTypeSignature(Type)` returns the JNI type signature that
    corresponds to the `System.Type`.
  * `GetType(JniTypeSignature)` returns the `Type` that corresponds
    to a JNI type signature.

One can imagine 1:1 *identity relation* between Java and managed
types, in which `GetType(GetTypeSignature(t))==t`:

	static void Identity<T> ()
	{
	  JniRuntime.JniTypeManager tm  = Java.Interop.JniEnvironment.Runtime.TypeManager;
	  JniTypeSignature  sigFromT    = tm.GetTypeSignature (typeof (T));
	  Type?             typefromSig = tm.GetType (sigFromT);
	  if (typeof (T) != typefromSig)
	    throw new Exception ($"Type({typeof (T)}) != .GetType({sigFromT}){{{(typefromSig == null ? "<null>" : typefromSig.ToString ())}}}");
	  JniTypeSignature  sigIdentity = tm.GetTypeSignature (typefromSig!);
	  if (sigFromT != sigIdentity)
	    throw new Exception ($"{sigFromT}) != {sigIdentity}");
	}

This is *not* always true in .NET for Android.

There *is* a required 1:1 relation between Java and managed types for
"normal" user-written `Java.Lang.Object` and `Java.Lang.Throwable`
subclasses, such as:

	partial class MainActivity : Activity {
	}

There *may not* be a 1:1 relation between Java and managed types for:

  * Bindings/projections of Java types; that is, types which have
    `[Register(…, DoNotGenerateAcw=true)]` or
    `[JniTypeSignature(…, GenerateJavaPeer=false)]`.

  * *Arrays* of types.  The same `JniTypeSignature` is generated for
    for `T[]`, `JavaArray<T>`, and other `Java*Array` types.

For example, `Mono.Android.dll` contains *three* "binding aliases"
for `java.util.ArrayList`:

  * `Android.Runtime.JavaList`
  * `Android.Runtime.JavaList<T>`
  * `Java.Util.ArrayList`

Only `Identity<Android.Runtime.JavaList>()` passes on .NET 9.

There are *two* binding aliases for `java.lang.Object`:
`Java.Interop.JavaObject, Java.Interop` and
`Java.Lang.Object, Mono.Android`.  (Plus more in unit tests!)
Only `Identity<Java.Lang.Object>()` passes on .NET 9, and that's
because of special-casing (25d1f007, 7acf328e).

Which brings us to 684ede6a and dotnet/android#9846: there are two
additional issues with the improved NativeAOT-compatible typemap:

 1. It ignores assembly names when generating typemaps, and
 2. It doesn't properly deal with binding aliases.

## Assembly Identity is important!

It is not unusual for developers to copy and paste code
"from elsewhere" into their project.  It is likewise not unusual for
developers to *not* rename such copied code, meaning it is quite
possible for the "same" type to be present multiple times in an app:

	// Lib1.dll
	namespace Utilities {
	    class GenericHolder<T> : Java.Lang.Object {
	        public T Value {get; set;}
	    }
	}

	// Lib2.dll
	namespace Utilities {
	    class GenericHolder<T> : Java.Lang.Object {
	        public T Value {get; set;}
	    }
	}

From a C# and .NET perspective, this is fine:
`Utilities.GenericHolder<T>` has `internal` visibility; there is no
conflict here.

…except in pre-2014 Xamarin.Android, in which the package name of the
Java Callable Wrapper (JCW) name was based on the namespace of the
managed type.  *Both* of the above types would have the *same* JCW
name: `utilities.GenericHolder`.  This would promptly error out:

	error : Duplicate managed type found! Mappings between managed types and Java types must be unique.
	First Type: 'Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, Xamarin.Android.Support.v4-r18, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null';
	Second Type: 'Android.Support.V4.App.FragmentManager/IOnBackStackChangedListenerImplementor, Mono.Android.Support.v4'

This scenario was improved in xamarin/monodroid@eb04c91c, which used
an *md5sum* of the namespace and assembly name, ensuring that the two
different `GenericHolder<T>` types would get different Java package
names, as the assembly name was in play.  (This was later changed to
use a CRC64 instead md5sum in dotnet/java-interop@397013ed.)

A problem in 684ede6a is that it would hash the managed type name for
a lookup, but the hash ignored the assembly name.  Consequently when
it countered two different `Java.InteropTests.GenericHolder<T>` types
in two separate assemblies, the assembly name was ignored, resulting
in a duplicate hash.  This would result in build failures:

	Fatal error in IL Linker
	Unhandled exception. System.InvalidOperationException: Duplicate hashes
	   at Microsoft.Android.Sdk.ILLink.TypeMappingStep.<>c__DisplayClass9_0.<EndProcess>g__GenerateHashes|10(UInt64[] hashes, String methodName)
	   at Microsoft.Android.Sdk.ILLink.TypeMappingStep.EndProcess()
	   at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
	   at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
	   at Mono.Linker.Pipeline.Process(LinkContext context)
	   at Mono.Linker.Driver.Run(ILogger customLogger)
	   at Mono.Linker.Driver.Main(String[] args)

Fix this by hashing `Type.AssemblyQualifiedName` instead of
`Type.FullName`.

## Binding Aliases

dotnet/android#9846 had a unit test failure in
`JavaObjectExtensionsTests.JavaCast_BaseToGenericWrapper()`:

	System.ArgumentException : Could not determine Java type corresponding to ``Android.Runtime.JavaList`1[[System.Int32, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Mono.Android``. Arg_ParamName_Name, targetType
	   at Java.Interop.JniRuntime.JniValueManager.CreatePeer(JniObjectReference&, JniObjectReferenceOptions, Type) + 0x248
	   at Java.Interop.JniRuntime.JniValueManager.GetPeer(JniObjectReference, Type) + 0x77
	   at Java.Lang.Object.GetObject(IntPtr, JniHandleOwnership, Type) + 0x31
	   at Java.Interop.JavaObjectExtensions._JavaCast[TResult](IJavaObject) + 0x66
	   at Java.InteropTests.JavaObjectExtensionsTests.JavaCast_BaseToGenericWrapper() + 0x62
	   at libMono.Android.NET-Tests!<BaseAddress>+0x1489b83
	   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0xf3

This is due to "binding aliases": there was no type mapping between
`Android.Runtime.JavaList<T>` and `java/util/arrayList`, because the
typemaps were assuming a 1:1 mapping, which isn't the case here.

Update `TypeMappingStep` so that binding aliases are supported.

Given (from `TypeMappingStep.cs`):

	partial class TypeMappingStep {
	  IDictionary<string, List<TypeDefinition>> TypeMappings = new(StringComparer.Ordinal);
	}

Then at the end of trimming, `TypeMappingStep.TypeMappings` will
contain e.g.

	TypeMappingStep.TypeMappings = {
	  ["java/util/ArrayList"]   => new List<TypeDefinition> {
	    typeof (Android.Runtime.JavaList),
	    typeof (Android.Runtime.JavaList<>),
	    typeof (Java.Util.ArrayList),
	  },
	  ["java/lang/Object"]      => new List<TypeDefinition> {
	    typeof (Java.Lang.Object),
	    typeof (Java.Interop.JavaObject),
	  },
	  ["java/lang/Runnable"]    => new List<TypeDefinition> {
	    typeof (Java.Lang.IRunnable),
	    typeof (Java.Lang.IRunnableInvoker),
	  },
	  // …
	};

From `TypeMappingStep.TypeMappings` we produce two typemap "tables".

Java/JNI class name to managed type resembles:

	partial class TypeMapping {

	  static Type? GetTypeByJniNameHashIndex (int index) => index switch {
	    0  => Type.GetTypeFromHandle (typeof (Java.Lang.Byte).RuntimeTypeHandle),           // `java/lang/Byte`         hash=0x01cd624f1e38cc9f
	    32 => Type.GetTypeFromHandle (typeof (Android.Runtime.JavaList).RuntimeTypeHandle),	// `java/util/ArrayList`    hash=0x7b925bdca68a0101
	    56 => Type.GetTypeFromHandle (typeof (Java.Lang.Object).RuntimeTypeHandle),         // `java/lang/Object`       hash=0xbf6d427143271cb3 
	    77 => Type.GetTypeFromHandle (typeof (Java.Lang.IRunnable).RuntimeTypeHandle),      // `java/lang/Runnable`     hash=0xfd2b1a3de667eb51
	    _  => null,
	  };

	  static string? GetJniNameByJniNameHashIndex (int index) => index switch {
	    0  => "java/lang/Byte",         // `Java.Lang.Byte, Mono.Android`           hash=0x01cd624f1e38cc9f
	    32 => "java/util/ArrayList",    // `Android.Runtime.JavaList, Mono.Android` hash=0x7b925bdca68a0101
	    56 => "java/lang/Object",       // `Java.Lang.Object, Mono.Android`         hash=0xbf6d427143271cb3
	    77 => "java/lang/Runnable",     // `Java.Lang.IRunnable, Mono.Android`      hash=0xfd2b1a3de667eb51
	    _  => null,
	  };

	  private static ReadOnlySpan<ulong>  JniNameHashes => new ReadOnlySpan<ulong>(ref s_get_JniNameHashes_data, 78);

	  [StructLayout(LayoutKind.Explicit, Pack=1, Size=624)]
	  private struct HashesArray_624 {
	  }
	  private static HashesArray_624      s_get_JniNameHashes_data = new ulong[78]{ // RVA data; insert hand-waving here
	    0x1cd624f1e38cc9f,   //    0: java/lang/Byte
	    // …
	    0x7b925bdca68a0101,  //   32: java/util/ArrayList
	    // …
	    0xbf6d427143271cb3,  //   56: java/lang/Object
	    // …
	    0xfd2b1a3de667eb51,  //   77: java/lang/Runnable
	    // …
	  };
	}

Note that `TypeMapping.GetTypeByJniNameHashIndex()` and
`TypeMapping.GetJniNameByJniNameHashIndex()` provides values for all
indexes between 0 and the number of hashes within
`s_get_JniNameHashes_data`.  Not all entries are listed for
exposition purposes.

Managed type to JNI resembles:

	partial class TypeMapping {

	  static string? GetJniNameByTypeNameHashIndex (int index) => index switch {
	    0   => "java/lang/IndexOutOfBoundsException", // `Java.Lang.IndexOutOfBoundsException, Mono.Android`    hash=0x0242f4a673f183d1
	    2   => "java/util/ArrayList",                 // `Java.Util.ArrayList, Mono.Android`                    hash=0x07c2b62d20a668dd
	    4   => "java/util/ArrayList",                 // `Android.Runtime.JavaList`1, Mono.Android`             hash=0x132055d1acecc87d
	    30  => "java/lang/Runnable",                  // `Java.Lang.IRunnableInvoker, Mono.Android`             hash=0x386176afae6775ce
	    32  => "mono/java/lang/Runnable",             // `Java.Lang.Runnable, Mono.Android`                     hash=0x408566f4617e204f
	    36  => "java/util/ArrayList",                 // `Android.Runtime.JavaList, Mono.Android`               hash=0x48a63a89cfee545f
	    44  => "java/lang/Object",                    // `Java.Lang.Object, Mono.Android`                       hash=0x5b4a99c45538d0fb
	    51  => "java/lang/Object",                    // `Java.Interop.JavaObject, Java.Interop`                hash=0x88a12107f88ba9a7
	    53  => "java/lang/Byte",                      // `Java.Lang.Byte, Mono.Android`                         hash=0x8ab15b52718902fb
	    96  => "java/lang/Runnable",                  // `Java.Lang.IRunnable, Mono.Android`                    hash=0xef2efa58a51bb883 
	    _   => null,
	  };

	  static string? GetTypeNameByTypeNameHashIndex (int index) => index switch {
	    0   => "Java.Lang.IndexOutOfBoundsException, Mono.Android",   // `java/lang/IndexOutOfBoundsException`  hash=0x0242f4a673f183d1
	    2   => "Java.Util.ArrayList, Mono.Android",                   // `java/util/ArrayList`                  hash=0x07c2b62d20a668dd
	    4   => "Android.Runtime.JavaList`1, Mono.Android",            // `java/util/ArrayList`                  hash=0x132055d1acecc87d
	    30  => "Java.Lang.IRunnableInvoker, Mono.Android",            // `java/lang/Runnable`                   hash=0x386176afae6775ce
	    32  => "Java.Lang.Runnable, Mono.Android",                    // `mono/java/lang/Runnable`              hash=0x408566f4617e204f
	    36  => "Android.Runtime.JavaList, Mono.Android",              // `java/util/ArrayList`                  hash=0x48a63a89cfee545f
	    44  => "Java.Lang.Object, Mono.Android",                      // `java/lang/Object`                     hash=0x5b4a99c45538d0fb
	    51  => "Java.Interop.JavaObject, Java.Interop",               // `java/lang/Object`                     hash=0x88a12107f88ba9a7
	    53  => "Java.Lang.Byte, Mono.Android",                        // `java/lang/Byte`                       hash=0x8ab15b52718902fb
	    96  => "Java.Lang.IRunnable, Mono.Android",                   // `java/lang/Runnable`                   hash=0xef2efa58a51bb883
	    _   => null,
	  };

	  private static ReadOnlySpan<ulong>  TypeNameHashes => new ReadOnlySpan<ulong>(ref s_get_TypeNameHashes_data, 99);

	  [StructLayout(LayoutKind.Explicit, Pack=1, Size=792)]
	  private struct HashesArray_792 {
	  }
	  private static HashesArray_792      s_get_TypeNameHashes_data = new ulong[99] { // RVA data; insert hand-waving here
	    0x242f4a673f183d1,   //    0: Java.Lang.IndexOutOfBoundsException, Mono.Android
	    // …
	    0x7c2b62d20a668dd,   //    2: Java.Util.ArrayList, Mono.Android
	    // …
	    0x132055d1acecc87d,  //    4: Android.Runtime.JavaList`1, Mono.Android
	    // …
	    0x386176afae6775ce,  //   30: Java.Lang.IRunnableInvoker, Mono.Android
	    // …
	    0x408566f4617e204f,  //   32: Java.Lang.Runnable, Mono.Android
	    // …
	    0x48a63a89cfee545f,  //   36: Android.Runtime.JavaList, Mono.Android
	    // …
	    0x5b4a99c45538d0fb,  //   44: Java.Lang.Object, Mono.Android
	    // …
	    0x88a12107f88ba9a7,  //   51: Java.Interop.JavaObject, Java.Interop
	    // …
	    0x8ab15b52718902fb,  //   53: Java.Lang.Byte, Mono.Android
	    // …
	    0xef2efa58a51bb883,  //   96: Java.Lang.IRunnable, Mono.Android
	    // …
	  };
	}

Note that `TypeMapping.GetJniNameByTypeNameHashIndex()` and
`TypeMapping.GetTypeNameByTypeNameHashIndex()` provides values for all
indexes between 0 and the number of hashes within
`s_get_TypeNameHashes_data`.  Not all entries are listed for
exposition purposes.

[jonpryor]

Please use the TypeDefinition.GetAssemblyQualifiedName(string, IMetadataResolver) extension method overload, if possible:
https://github.com/dotnet/java-interop/blob/main/src/Java.Interop.Tools.Cecil/Java.Interop.Tools.Cecil/TypeDefinitionRocks.cs#L162-L173

We have found that providing and using the cache significantly speeds things up, and this code doesn't use a TypeDefinitionCache or IMetadataResolver cache.

[jonpryor]

Coding style: I prefer "one expression per line", and would prefer:

var orderedManagedToJavaMapping = TypeMappings
    .SelectMany(kvp => kvp.Value.Select (type => new KeyValuePair<string, string>(kvp.Key, type.GetAssemblyQualifiedTypeName (cache))))
    .OrderBy (kvp => Hash (kvp.Value))
    .ToArray ();

[dellis1972]

@grendello are we till trying to avoid using Linq in the tasks and linker steps?

[grendello]

I'd hope so, it's still slower than plain, old, boring, hand-written code :)

[simonrozsival]

I can remove the LINQ queries in a follow-up PR.

[simonrozsival]

@jonpryor:

The generated IL includes several structs, (static) fields, properties, and methods:

• RVA static fields containing the raw bytes of ulong[]
  • s_get_JavaClassNameHashes_data
  • s_get_TypeNameHashes_data
• structs with explicit layout for the RVA static fields with an exact size ($"HashesArray_{bytes.Length}")
• property getters which convert the RVA static fields into ReadOnlySpan<ulong>
  • ReadOnlySpan<ulong> TypeNameHashes { get; }
  • ReadOnlySpan<ulong> JavaClassNameHashes { get; }
• lookup methods containing switch over index returning constants:
  • Type GetTypeByIndex(int index)
  • string GetJavaClassNameByTypeIndex(int index)
  • string GetJavaClassNameByIndex(int index)
  • string GetAssemblyQualifiedTypeNameByJavaClassNameIndex(int index)

Example of generated IL:

.class private auto ansi abstract sealed beforefieldinit Microsoft.Android.Runtime.TypeMapping
	extends [System.Private.CoreLib]System.Object
{
	// Nested Types
	.class nested private explicit ansi HashesArray_432
		extends [System.Private.CoreLib]System.ValueType
	{
		.pack 1
		.size 432
	} // end of class HashesArray_432

	.class nested private explicit ansi HashesArray_520
		extends [System.Private.CoreLib]System.ValueType
	{
		.pack 1
		.size 520
	} // end of class HashesArray_520

	// Fields
	.field private static initonly valuetype Microsoft.Android.Runtime.TypeMapping/HashesArray_432 s_get_JavaClassNameHashes_data at I_000050A0
	.data cil I_000050A0 = bytearray (
		9a 01 29 fb 99 a6 1d 0b c5 ed d9 21 2c 4c 7b 10
		...	
		38 16 36 2e 22 5f db e6 b3 e1 9b aa 70 ed 49 ed
		cc 69 d3 a1 96 29 2f ef 51 eb 67 e6 3d 1a 2b fd
	)

	.field private static initonly valuetype Microsoft.Android.Runtime.TypeMapping/HashesArray_520 s_get_TypeNameHashes_data at I_00005250
	.data cil I_00005250 = bytearray (
		61 6f 2b de bc 40 ae 06 74 67 7e 91 a6 74 86 0e
		...
		fe 76 b3 29 61 10 54 e5 4e d8 0d fd 3f 62 db e7
		83 b8 1b a5 58 fa 2e ef d2 37 aa 89 d5 ea 22 f0
		7c b2 61 76 1c b7 83 f9
	)

	.method private hidebysig specialname static 
		valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64> get_TypeNameHashes () cil managed 
	{
		// Method begins at RVA 0x4584
		// Header size: 12
		// Code size: 16 (0x10)
		.maxstack 2
		.locals init (
			[0] valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64>
		)

		IL_0000: ldsflda valuetype Microsoft.Android.Runtime.TypeMapping/HashesArray_520 Microsoft.Android.Runtime.TypeMapping::s_get_TypeNameHashes_data
		IL_0005: ldc.i4 65
		IL_000a: newobj instance void valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64>::.ctor(void*, int32)
		IL_000f: ret
	} // end of method TypeMapping::get_TypeNameHashes

	.method private hidebysig specialname static 
		valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64> get_JavaClassNameHashes () cil managed 
	{
		// Method begins at RVA 0x4b1c
		// Header size: 12
		// Code size: 16 (0x10)
		.maxstack 2
		.locals init (
			[0] valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64>
		)

		IL_0000: ldsflda valuetype Microsoft.Android.Runtime.TypeMapping/HashesArray_432 Microsoft.Android.Runtime.TypeMapping::s_get_JavaClassNameHashes_data
		IL_0005: ldc.i4 54
		IL_000a: newobj instance void valuetype [System.Private.CoreLib]System.ReadOnlySpan`1<uint64>::.ctor(void*, int32)
		IL_000f: ret
	} // end of method TypeMapping::get_JavaClassNameHashes

	.method private hidebysig static 
		class [System.Private.CoreLib]System.Type GetTypeByIndex (
			int32 index
		) cil managed 
	{
		.custom instance void [System.Private.CoreLib]System.Runtime.CompilerServices.NullableContextAttribute::.ctor(uint8) = (
			01 00 02 00 00
		)
		// Method begins at RVA 0x45a0
		// Header size: 12
		// Code size: 823 (0x337)
		.maxstack 1

		IL_0000: ldarg.0
		IL_0001: switch (IL_00e3, ..., IL_032a)

		IL_00de: br IL_0335

		IL_00e3: ldtoken [Mono.Android]Android.OS.BaseBundle
		IL_00e8: call class [System.Private.CoreLib]System.Type [System.Private.CoreLib]System.Type::GetTypeFromHandle(valuetype [System.Private.CoreLib]System.RuntimeTypeHandle)
		IL_00ed: ret

		...

		IL_032a: ldtoken [Mono.Android]Java.Lang.IRunnable
		IL_032f: call class [System.Private.CoreLib]System.Type [System.Private.CoreLib]System.Type::GetTypeFromHandle(valuetype [System.Private.CoreLib]System.RuntimeTypeHandle)
		IL_0334: ret

		IL_0335: ldnull
		IL_0336: ret
	} // end of method TypeMapping::GetTypeByIndex

	.method private hidebysig static 
		string GetJavaClassNameByTypeIndex (
			int32 index
		) cil managed 
	{
		.custom instance void [System.Private.CoreLib]System.Runtime.CompilerServices.NullableContextAttribute::.ctor(uint8) = (
			01 00 02 00 00
		)
		// Method begins at RVA 0x48e4
		// Header size: 12
		// Code size: 553 (0x229)
		.maxstack 1

		IL_0000: ldarg.0
		IL_0001: switch (IL_00e3, ..., IL_0221)

		IL_00de: br IL_0227

		IL_00e3: ldstr "android/os/BaseBundle"
		IL_00e8: ret

		... 

		IL_0221: ldstr "java/lang/Runnable"
		IL_0226: ret

		IL_0227: ldnull
		IL_0228: ret
	} // end of method TypeMapping::GetJavaClassNameByTypeIndex

	.method private hidebysig static 
		string GetJavaClassNameByIndex (
			int32 index
		) cil managed 
	{
		.custom instance void [System.Private.CoreLib]System.Runtime.CompilerServices.NullableContextAttribute::.ctor(uint8) = (
			01 00 02 00 00
		)
		// Method begins at RVA 0x4b38
		// Header size: 12
		// Code size: 663 (0x297)
		.maxstack 1

		IL_0000: ldarg.0
		IL_0001: switch (IL_010f, ..., IL_028f)

		IL_010a: br IL_0295

		IL_010f: ldstr "android/content/Context"
		IL_0114: ret

		...

		IL_028f: ldstr "java/lang/Throwable"
		IL_0294: ret

		IL_0295: ldnull
		IL_0296: ret
	} // end of method TypeMapping::GetJavaClassNameByIndex

	.method private hidebysig static 
		string GetAssemblyQualifiedTypeNameByJavaClassNameIndex (
			int32 index
		) cil managed 
	{
		.custom instance void [System.Private.CoreLib]System.Runtime.CompilerServices.NullableContextAttribute::.ctor(uint8) = (
			01 00 02 00 00
		)
		// Method begins at RVA 0x4ddc
		// Header size: 12
		// Code size: 663 (0x297)
		.maxstack 1

		IL_0000: ldarg.0
		IL_0001: switch (IL_010f, ..., IL_028f)

		IL_010a: br IL_0295

		IL_010f: ldstr "Android.Content.ContextInvoker, Mono.Android, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"
		IL_0114: ret

		...

		IL_028f: ldstr "Java.Lang.Throwable, Mono.Android, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065"
		IL_0294: ret

		IL_0295: ldnull
		IL_0296: ret
	} // end of method TypeMapping::GetAssemblyQualifiedTypeNameByJavaClassNameIndex

} // end of class Microsoft.Android.Runtime.TypeMapping

[jonpryor]

I don't think we want or need to use the "full" .AssemblyQuaifiedName value here and in GetAssemblyQualifiedTypeNameByJavaClassNameIndex(), because all we really care about is assembly identity, not assembly versions; we have no mechanism to e.g. package both System.Drawing.dll v2.0 and v4.0. We don't have a GAC. Only one assembly version is ever packaged.

By using e.g. Android.Content.ContextInvoker, Mono.Android instead of Android.Content.ContextInvoker, Mono.Android, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065, we save 67*2=134 bytes in the resulting IL, "simply" by not storing data that we don't care about.

[simonrozsival]

You're right—we don't need the full AQN; the simple assembly name is enough for this use case. I'll revisit this.

I'm still unsure whether we need a hash collision check at all. The current native type map omits it, relying on xxHash64's extremely low collision probability.

[jonpryor]

Even if we do need it, I'm not sure why we need to be checking for collisions at runtime. A hash collision can be checked at build time.

[simonrozsival]

You can still have a runtime hash collision even when we check for build-time collisions. When someone passes an object to a marshal method and we try to look up its corresponding managed type, we ask the Java object for its class name and use that as an input to the type map.

This class name might be something we have not seen at build time (it could be some internal subclass of the base class we know at build time). Now when we hash this previously unknown class name, there's a positive chance it will collide with some hash of a different class name which is present in the type map.

The chance of this is very very close to zero and it likely wouldn't be possible to hit unless somebody constructs the input class name very carefully to achieve the collision. I don't know how that could be useful for an "attacker" though and if that's something we should or need to cover.

[simonrozsival]

I don't think we want or need to use the "full" .AssemblyQuaifiedName value here and in GetAssemblyQualifiedTypeNameByJavaClassNameIndex(), because all we really care about is assembly identity, not assembly versions; we have no mechanism to e.g. package both System.Drawing.dll v2.0 and v4.0. We don't have a GAC. Only one assembly version is ever packaged.

We discussed this with @jonathanpeppers and the reason for using AQN was that it's much faster than calling assembly.GetName():

[Benchmark]
public string GetTypeAssemblyQualifiedName()
{
    var type = typeof(string);
    return type.AssemblyQualifiedName;
}

[Benchmark]
public string GetAssemblyName()
{
    var type = typeof(string);
    return $"{type.FullName}, {type.Assembly.GetName().Name}";
}

Method	Mean	Error	StdDev
GetTypeAssemblyQualifiedName	35.79 ns	0.590 ns	1.123 ns
GetAssemblyName	407.84 ns	8.162 ns	13.860 ns

I updated the code to trim the unwanted suffix of the AssemblyQualifiedName to keep the perf of AssemblyQualifiedName but avoid those version mismatches.

[jonpryor]

@simonrozsival: I've partially updated the draft commit message based on your your provided IL, but I'm still not sure I understand the "managed type to Java" mechanism.

Would it be possible to update your IL with the "known duplicates" -- assuming they survived trimming -- of Java.Interop.JavaObject + Java.Lang.Object, and/or Android.Runtime.JavaList + Android.Runtime.JavaList<T> + Java.Util.ArrayList?

Additionally, why is GetAssemblyQualifiedTypeNameByJavaClassNameIndex() mentioning Android.Content.ContextInvoker? Shouldn't it be using Android.Content.Context? Especially given SelectTypeDefinition(), which prefers abstract types?

From TryGetJavaClassName():

1. ulong hash = Hash(type.AssemblyQualifiedName)

2. int javaClassNameIndex = MemoryExtensions.BinarySearch (TypeNameHashes, hash);

   This is where I get confused; javaClassNameIndex is the index into TypeNameHashes of the hash value. But when we're dealing with "aliases", in which two different managed type names should refer to the same Java class name, how does this work? They should have different javaClassNameIndex values.

My expectation is that both TryGetJavaClassName(typeof(Android.Runtime.JavaList), …) and TryGetJavaClassName(typeof(Java.Util.ArrayList), …) would both "return" java/util/ArrayList, but I don't see how that is possible here.

Unrelatedly, the "ByIndex" methods are starting to confuse me. By what index? I think we need more nouns, especially as we only have two of these mappings running around and nomenclature is already annoying. Consider "GetJavaClassNameByTypeIndex"; which type? Managed or Java?

Perhaps:

• GetTypeByIndex => GetTypeByTypeNameHashesIndex
• GetJavaClassNameByTypeIndex => GetJavaClassNameByTypeNameHashesIndex
• GetJavaClassNameByIndex => GetJavaClassNameByJavaClassNameHashesIndex

which would match the convention of "GetAssemblyQualifiedTypeNameByJavaClassNameIndex", which also re-emphasizes my concern around type aliases above:

[simonrozsival]

This is where I get confused; javaClassNameIndex is the index into TypeNameHashes of the hash value. But when we're dealing with "aliases", in which two different managed type names should refer to the same Java class name, how does this work? They should have different javaClassNameIndex values.

@jonpryor if I understand your example, it is not clear to you how two different types can map to the same Java class name when they have different indexes into the TypeNameHashes table?

The answer is that there can be duplicate return values in the switch, as you correctly outlined it in the draft commit message:

static ulong[] s_get_TypeNameHashes_data = { 
    /* 0: */ 0xA, // xxhash64("Android.Runtime.JavaList"),
    /* 1: */ 0xB, // xxhash64("Java.Util.ArrayList"),
    ...
};

static string GetJavaClassNameByIndex(int typeNameHashesIndex)
    => typeNameHashesIndex switch {
        0 => "java/util/ArrayList",
        1 => "java/utilArrayList",
        ...
    };

static string GetAssemblyQualifiedTypeNameByIndex(int typeNameHashesIndex)
    => typeNameHashesIndex switch {
        0 => "Android.Runtime.JavaList, ...",
        1 => "Java.Util.ArrayList, ...",
        ...
    };

When the input is typeof(Android.Runtime.JavaList), this would be the order of operations:
1. The AQN "Android.Runtime.JavaList, ..." is hashed using xxhash64 -> 0xA
2. we find the index in TypeNameHashes using binary search -> 0
3. we confirm that the AQN of the input is actually correct and it is not just a hash collision by calling GetAssemblyQualifiedTypeNameByIndex(0)
4. we find the Java class name by calling GetJavaClassNameByIndex(0) -> "java/util/ArrayList"
5. we return the final string "java/util/ArrayList"

2. int javaClassNameIndex = MemoryExtensions.BinarySearch (TypeNameHashes, hash);

This is where I get confused; javaClassNameIndex is the index into TypeNameHashes of the hash value. But when we're dealing with "aliases", in which two different managed type names should refer to the same Java class name, how does this work? They should have different javaClassNameIndex values.

The idea was that javaClassNameIndex is an index you would use to call the GetJavaClassNameByIndex method.
I agree that the *ByIndex suffixes are confusing and I like the names you suggested better. I will update the code based on your suggestion.

Additionally, why is GetAssemblyQualifiedTypeNameByJavaClassNameIndex() mentioning Android.Content.ContextInvoker? Shouldn't it be using Android.Content.Context? Especially given SelectTypeDefinition(), which prefers abstract types?

The GetAssemblyQualifiedTypeNameByJavaClassNameIndex method, which can return the "Android.Content.ContextInvoker" string, is used to confirm that there is no hash collision when typeof(Android.Content.ContentInvoker) is the input.

In other words, we won't return typeof(Android.Content.ContentInvoker) when we're looking for the managed type corresponding to "android/content/Context".

---

Related question: The more I keep working with this codebase, the more I'm starting to notice that I'm mixing the "Java class names" and "JNI names" without understanding the differences. Are JNI names class names where / is the separator and Java class names are separated with .? Should I also change the naming in the type map code?

[jonpryor]

@simonrozsival asked:

Related question: The more I keep working with this codebase, the more I'm starting to notice that I'm mixing the "Java class names" and "JNI names" without understanding the differences. Are JNI names class names where / is the separator and Java class names are separated with .?

The "JNI name" is a string value which can be provided to JNIEnv::FindClass(string):

The name argument is a fully-qualified class name or an array type signature . For example, the fully-qualified class name for the java.lang.String class is:

"java/lang/String"

It's not "just" a "replace all .s with / from the Java class name". The problem is nested types, such as java.lang.Thread.UncaughtExceptionHandler. In Java, as with C#, nested types are separated from their declaring types with .. In JNI, as with IL, nested types are separated from their declaring types using a character other than .; JNI uses $, while IL uses / (and Reflection uses +).

Thus, the unambiguous name is always the JNI name, just as in .NET the unambiguous name is Type.AssemblyQualifiedName (+ not . for nested types):

• Java: java.lang.Thread.UncaughtExceptionHandler
• JNI: java/lang/Thread$UncaughtExceptionHandler

Should I also change the naming in the type map code?

This would be a good idea.

[simonrozsival]

@jonpryor I renamed the methods, properties, and local variables. The names are now more descriptive. I chose to stick to names such as typeName and GetJniNameByTypeNameHashIndex instead of managedTypeName and GetJniNameByManagedTypeNameHashIndex since I believe it's clear that we're talking about managed types as counterparts of JNI names and adding managed to all the names didn't seem helpful. Please have anogher look.

[jonpryor]

Not sure what's up with GitHub, but devops is now green: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=11218551&view=results