Xamarin Android garbage collection algorithm

Question

I am reading the Xamarin.Android garbage collection docs about helping the GC perform better by reducing referenced instances.

The section begins by saying:

Whenever an instance of a Java.Lang.Object type or subclass is scanned during the GC, the entire object graph that the instance refers to must also be scanned. The object graph is the set of object instances that the "root instance" refers to, plus everything referenced by what the root instance refers to, recursively.

...which I understand.

It then goes to show a custom class inheriting from the standard Activity class. This custom activity class has a field that is a list of strings which is initialized in the constructor to have 10,000 strings. This is said to be bad because all 10,000 instances will have to be scanned for reachability during GC. That I also understand.

The part that I am not clear on, is the recommended fix: it says the List<string> field should be moved to another class that doesn't inherit from Java.Lang.Object and then an instance of that class should be referenced from the activity just like the list was being referenced before.

My question: how does pushing a field deeper into the object graph help the GC when the total number of instances is still 10,000 and the opening paragraph says they will be scanned eventually because the process is recursive?

As a side note, I am also reading up (here) on the SGen GC used by Mono on Android and the object graph traversal process is described as being breadth-first starting with the GC roots. This explains how a 10,000 item list will cause a longer GC pause as each item is checked, but still doesn't explain how moving that list deeper into the graph will help because the GC will eventually scan it as it goes deeper into the graph.

Answer 1

I'll try to explain this the best I can, and I'm nowhere near an expert here so anyone who wants to chime in, please do so.

When we are referring to doing a peer walk, we are locating any roots and traversing the live reference graph to see what is reachable and what is not:

Root Objects:

• Objects pointed at by static fields / properties
• Objects on the stack of each managed thread
• Objects that have been passed into native APIs

Basically you then have to deal with two managed GCs. We'll call them the Xamarin GC and the Android GC for reference.

Xamarin.Android has peer objects which are used to reference the native Java objects known in the Android JVM. They implement a core interface:

namespace Android.Runtime
{
    public interface IJavaObject : IDisposable
    {
        // JNI reference to the Java object it is wrapping. 
        // Also known as a pointer to the JVM object
        public IntPtr Handle { get; set; }
        ...
    }
}

Whenever we have an object with IJavaObject inherited, it will keep a strong reference via that JNI handle above to ensure it is kept alive as long as the managed object is alive.

Think of it this way:

IJavaObject -> IntPtr Handle -> Java Object

In GC terms, it would be represented as the following:

Allocated and collected by Xamarin GC -> GC Root -> Allocated and collected by Android GC

We then have a GC process in Xamarin.Android:

When the GC runs, you can see that it will replace a strong JNI handle with a weak reference and then invoke the Android GC which will collect our Java object. Because of this, the peers are scanned for any relationships to ensure that they are mirrored in the JVM. This keeps these objects from being collected prematurely.

Once this happens, we run the Android GC and when it's finished it will walk through the peer objects and check the weak references.

• If an object is gone, we collect it on the C# side
• If an object still exists, then we change the weak reference back to a strong JNI handle

Thus this graph needs to be checked and updated each time a GC runs on peer objects. That's why it's much slower for these wrapper type objects because the entire object graph has to be scanned starting at the peer object.

So when there are significant object graphs that our peer object uses, we can help out the GC process by moving the storage of the references outside the peer class. This is usually done by rooting our reference independent of the peer. And since it's not stored as a field, the GC will not try to do a relationship walk on the object graph.

As noted earlier, this isn't a huge issue to worry about until you notice long GCs. You can then use this as a solution.

Image Credit: Xamarin University(https://www.xamarin.com/university)