[Mono.Android] call new Java "GC Bridge" APIs

[jonathanpeppers]

Context: dotnet/runtime#114184
Context: https://github.com/AaronRobinsonMSFT/BridgeSandbox
Context: dotnet/runtime@main...BrzVlad:runtime:feature-clr-gcbridge

So far, I:

• Built dotnet/runtime, I built this branch:

https://github.com/jonathanpeppers/runtime/tree/gcbridge_impl

• Put the relevant arm64 packs in packages/ folder and configured a
  NuGet.config to use them.

• Setup build-tools\scripts\custom-runtime.targets to use the
  10.0.0-dev dotnet/runtime packs.

• In ManagedValueManager.cs...

• Call a new native method on startup:

var mark_cross_references_ftn = RuntimeNativeMethods.clr_initialize_gc_bridge (&BridgeProcessingFinished);

• Pass the returned function pointer to:

JavaMarshal.Initialize (mark_cross_references_ftn);

• In AddPeer(IJavaPeerable value) call JavaMarshal.CreateReferenceTrackingHandle()

• In RemovePeer(IJavaPeerable value) call:

static unsafe void FreeHandle (GCHandle handle)
{
    IntPtr context = JavaMarshal.GetContext (handle);
    NativeMemory.Free((void*)context);
}

Update

I added a second commit, of what it could look like if everything was managed/C# code.

[jonpryor]

This concerns me, because this value will change over time!

[jonpryor]

To elaborate, with MonoVM -- and thus I assume eventually with dotnet/runtime#114184 -- when a "bridged" instance is no longer reachable from the .NET GC, we:

1. "Toggle" JavaObject.PeerReference from a JNI Global Reference to a JNI Weak Global Reference.
2. Trigger a Java-side GC.
3. If the instance survives the Java-side GC, we "toggle" the JNI Weak Global Reference to a JNI Global Reference.

This means the value of value.PeerReference changes, because 1...3 will result in a different JNI Global Reference value.

Meaning using "value.PeerReference.Handle` is immediately "bad".

[jonpryor]

I also wonder if using value.PeerReference is necessary? It's for the userContext parameter; perhaps it could just be null?

E.g. CreateCrossReferenceHandle() calls CreateHandleWithExtraInfo() and providing userContext as the "extra info", and JavaMarshal.GetContext() returns GetExtraInfoFromHandle(), i.e. appears to return "userContext".

Aside: if true, this makes me think that JavaMarshal.GetContext() is mis-named, and should instead be called JavaMarshal.GetUserContext(), which would make the relationship more apparent.

[jonpryor]

…though, to be fair, it's CreateReferenceTrackingHandle(object obj, System.IntPtr context), so GetContext() does make sense…

[AaronRobinsonMSFT]

Where @jonpryor got to in the end is how this should be used. He is correct in that the PeerReference (assumed to be a JNI handle) should be contained within the allocated memory that is the "context". Renaming to "UserContext" is a reasonable request and we can workshop that in API review.

The PeerReference property could dereference the context pointer and get the JNI handle if desired. In fact, the context could be a pointer sized allocation or any size, store any addtiional details you want there.

[jonpryor]

What I suspect needs to happen is that JavaObject and JavaException need to be updated to have:

partial class JavaObject {
	// Remove the following members
	[NonSerialized] IntPtr                  handle;
	[NonSerialized] JniObjectReferenceType  handle_type;
	// Used by JavaInteropGCBridge
	[NonSerialized] IntPtr                  weak_handle;
	[NonSerialized] int                     refs_added;
}

and replace with:

internal struct JniObjectInfo {
	public IntPtr                  handle;
	public JniObjectReferenceType  handle_type;
	// Used by JavaInteropGCBridge
	public IntPtr                  weak_handle;
	public int                     refs_added;
}

partial class JavaObject {
	IntPtr JniObjectInfo = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(JniObjectInfo)));
}

…then update everything within JavaObject and JavaException to go "through" JniObjectInfo, e.g. instead of this.handle, do ((JniObjectInfo)this.JniObjectInfo).handle.

This would allow CreateReferenceTrackingHandle() to pass in value.JniObjectInfo, which is a non-moving block of per-instance memory, which would allow the GC bridge callback to reasonably access all needed members.

Further note: this in turn means that the appropriate starting point for this PR is in dotnet/java-interop, not dotnet/android.

[jonathanpeppers]

The new APIs are all decorated with:

[SupportedOSPlatform("android")]

• https://github.com/dotnet/runtime/pull/114184/files#diff-e450e8d216c66e851e0af9ba293ab3baafcfd505ebe758f1f255b5a512d369b1R10-R11

We can use them in java.interop, but would have to wrap them all with #pragma warning disable CA1416.

java.interop is also not building with TargetFramework=net10.0:

• https://github.com/dotnet/java-interop/blob/d909947536b53e802ecc9ee883ccc52d74651ede/Directory.Build.props#L12-L13

The new APIs will only be in .NET 10.

So, maybe we have to do a branch of java.interop that just updates JavaObject and JavaException combined with this PR?

[jonathanpeppers]

This is the C# binding of java.lang.System.gc(): https://developer.android.com/reference/java/lang/System#gc()

[jonathanpeppers]

I updated this to use:

• [Java.Interop] JNI handles are now in a "control block" java-interop#1334