Context: #13 What do we want? For cross-VM object references to work -- a java.util.ArrayList referencing a MyJavaObjectSubclass instance, and being the *only* reference, yet the MyJavaObjectSubclass instance isn't collected, *because* the Java-side ArrayList is keeping it alive. See also commit eb69a47. What we currently have is a terrible solution. (Even as a terrible solution, it's a terrible solution!) Fortunately, we know what we need to do: import the Xamarin.Android GC bridge implementation, which is (reasonably) well debugged and has been used for *years*. Update the java-interop native library, adding a new JavaInteropGCBridge API (in <java-interop-gc-bridge.h>), and implement that API for use on Mono. (Currently unknown: how feasible it'll be to provide a similar API for use with CoreCLR, which is an entirely different can of worms...) Changes from the Xamarin.Android GC bridge are as follows: * It's (mostly!) scoped to an instance of JavaInteropGCBridge, as opposed to the Xamarin.Android implementation, which is dozens of global variables. (There's still a global, but now it's just `mono_bridge`, which is a pointer to an easier-to-reason-about struct. * Code has been reformatted for consistency, and to conform to https://matt.sh/howto-c , which in turn follows common C++ practice -- declare variables at initialization, etc. * The JNIEnv.BridgeProcessing field is now the MonoRuntimeValueManager.GCBridgeProcessingIsActive field, though the *actual* field to use can be specified via java_interop_gc_bridge_set_bridge_processing_field(). * Instead of always using Java.Lang.Object and Java.Land.Throwable (from Mono.Android.dll) as brided types, allow the bridged types to be specified via java_interop_gc_bridge_register_bridgeable_type(). ...which is to say that there are some stylistic changes, but no concrete algorithm changes or structural changes to the GC bridge itself (aside from some function re-ordering). With the JavaInteropGCBridge API in place, *integrate* it with Java.Interop proper, which in turn is kinda complicated, as the GC bridge is specific to Mono (+SGEN!), and will not run on .NET. To square this circle, we make JniRuntime.JniValueManager an *abstract* type, with a new abstract WaitForGCBridgeProcessing() method, and concretely implement this type in Java.Interop.MonoRuntimeValueManager (in Java.Runtime.Environment.dll). We then do a runtime check to see if we're on mono; if we are, we use MonoRuntimeValueManager; otherwise, we through an exception so whoever is setting things up can provide their own JniRuntime.JniValueManager implementation. Update ExportedMemberBuilder so that JniEnvironment.Runtime.ValueManager.WaitForGCBridgeProcessing() is called at entry from unmanaged to managed code, as is done with JNIEnv.WaitForGCBridgeProcessing() in Xamarin.Android. Notes: * Xamarin.Android used mono_assembly_load_full() in order to load Mono.Android.dll and find the appropriate types. Trying to do this in java-interop caused a crash for an unexplored reason. To avoid the crash, mono_assembly_load_full() is *skipped* entirely. Instead, a System.RuntimeTypeHandle is passed from managed code to java-interop to act upon the intended types. This in turn raises a concern, as we're passing the System.RuntimeTypeHandle *structure* to P/Invoke, which *works*, but I don't know how *stable* that is gauranteed to be. *Better* would be to use RuntimeTypeHandle.Value (an IntPtr), but for some asinine reason that property is NOT in PCL Profile7, meaning I can't access it from a PCL lib. Question: How problematic is this? * The JavaInteropGCBridge logging implementation records the thread name and thread ID of the thread creating/destroying the JNI handle. This is currently done by registering a delegate from managed code, which uses Thread.CurrentThread.Name and Thread.ManagedThreadId. WANTED: A Mono embedding API which provides a way to get the thread name and thread id of a MonoThread* value. This would avoid an unmanaged > managed transition during logging. * The GC bridge sets the static MonoRuntimeValueManager.GCBridgeProcessingIsActive field within *all* AppDomains. This is so that Java.Interop can be used in multiple AppDomains...because why not? However, this is problematic because we're using mono_class_vtable() to get the MonoVTable* to set the static field, and mono_class_vtable() *always loads the type*, which is inappropriate if Java.Runtime.Environment.dll hasn't been loaded into the current AppDomain. WANTED: A Mono embedding API like mono_class_vtable() which returns NULL if the type hasn't already been loaded into the specified MonoDomain*. That way we can set MonoRuntimeValueManager.GCBridgeProcessingIsActive within the AppDomains that have it, but not *every* AppDomain. TODO: While this commit *adds* a GC bridge implementation, it is not currently *used*. Here are some of the things that need to be done to do that, among others: * Review the JniRuntime.JniValueManager API for sanity. Ideally it should be possible to implement "sanely" on .NET, though possibly *without* GC integration. Perhaps "manual" GCs are supportable, e.g. a JniRuntime.ValueManager.Collect() method which the developer must invoke occasionally. (Terrible, certainly, but possibly useful for prototypes?) * SafeHandles must be dropped -- disable FEATURE_JNIENVIRONMENT_SAFEHANDLES and use FEATURE_JNIENVIRONMENT_JI_PINVOKES (commit add10d1). JavaInteropGCBridge only knows about "handle" and "handle_type" fields (among others); it doesn't support SafeHandles, so in order for Java.Interop.JavaObject to be usable with JavaInteropGCBridge, we need to drop SafeHandle use. * JavaInteropGCBridge requires that the Java Callable Wrapper (formerly Android Callable Wrapper) provide methods named monodroidAddReference(java.lang.Object) and monodroidClearReferences(). No Java types within Java.Interop currently provide these methods, meaning the *very crucial glue* to support cross-VM object references is *missing*. We should provide a variant on the Xamarin.Android mono.android.IGCUserPeer interface for use with Java.Interop, and improve JavaInteropGCBridge to use the interface instead of looking up the jmethodID values afresh for every encountered type. * We have *two* separate JNI handle loggers now: one in java-interop, and one in LoggingJniObjectReferenceManagerDecorator. We should kill the LoggingJniObjectReferenceManagerDecorator type.

Mono GC Bridge Support #13

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions