GC: Support object level interop on Android

[mangod9]

This is a tracking issue for support Android scenarios on CoreCLR GC.

• Prototype using IReferenceTracker - repo
• Prototype using bespoke solution - demo and bridge custom runtime
• Implement the GC Bridge
  • Get new API approved
  • CoreCLR
  • native AOT

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[filipnavara]

I did some experiment with running the MonoVM GC bridge code inside NativeAOT runtime - https://github.com/filipnavara/runtime/tree/javainterop. Notes: https://gist.github.com/filipnavara/17430066bdc3a9dce10ab65a46ae5dc4

Feel free to take any inspiration from it.

[jkotas]

cc @AaronRobinsonMSFT

[cshung]

@filipnavara, I have read through the algorithm described in the paper.
I am wondering how exactly do we mirror the references once we have the compressed reference graph?

[AaronRobinsonMSFT]

I am wondering how exactly do we mirror the references once we have the compressed reference graph?

This would follow the existing solution in Java interop. See add_reference and gc_cleanup_after_java_collection. The contract interface on the Java side is GCUserPeerable.

[filipnavara]

I was about to post what @AaronRobinsonMSFT did. However, there is a small nuance that is missing from the java-interop bridge and that is present in the Android bridge / MonoVM's sgen-tarjan-bridge. Sometimes it's inefficient to remove all C# objects from the compressed graph. For example, consider having a C# array AR = new JavaObject[1000] with each element pointing to a Java peer object, and three Java objects A, B, and C each pointing to the array AR and becoming collectible (as in, not having C# references; and having the C# projections becoming unreferenced). If you fully compress the graphs you end up with 3000 edges in the graph that need to be transferred to the Java VM. However, instead of doing that, you can represent the C# array as ArrayList on the Java side. By doing that you add 3 references to the ArrayList through the GCUserPeerable interface, and you create the ArrayList itself through JNI and simply abandon it at the end of the process. This essentially reduces the complexity from transferring 3000 edges to 1003 edges + 1 list allocation.

More generally, any node in the object graph that is pure C# object without Java peer can be represented as ArrayList on the Java side.

Just to summarize:

• .NET projections of existing Java code (ie. wrapping existing unmodified Java class) cannot have references to other C# object unless the references are projected Java objects. For example, projection of Activity would fall in this category. It can reference implementations of ActivityLifecycleCallbacks that get attached through registerActivityLifecycleCallbacks, those implementations can be written in C# but they will themselves have Java projections.
• .NET implementations of Java objects (including Java interface implementations, or objects inherited from existing Java classes) have the Java side of the projection generated by the dotnet/java-interop tooling and it implements the GCUserPeerable protocol on the Java VM side.
• Any non-peer .NET node in the graph can be represented as ArrayList on the Java VM side.

[AaronRobinsonMSFT]

However, there is a small nuance that is missing from the java-interop bridge and that is present in the Android bridge / MonoVM's sgen-tarjan-bridge.

I wasn't aware of this optimization. Can you share where the ArrayList creation is performed?

[filipnavara]

Can you share where the ArrayList creation is performed?

https://github.com/dotnet/android/blob/627e239f8296ebd35101a80041fa6c95cbf8efd1/src/native/monodroid/osbridge.cc#L786-L818

[filipnavara]

(Apparently the ArrayList is wrapped in a GCUserPeer class but that's an implementation detail.)