Xamarin Android垃圾收集算法 [英] Xamarin Android garbage collection algorithm

问题描述

我正在阅读Xamarin.Android垃圾回收文档，帮助GC更好地执行

根对象：

• 对象由静态字段/属性指向


• 每个托管线程的堆栈中的对象


• 分为本地API

基本上，您必须处理两个托管GC。我们将它们称为Xamarin GC和Android GC以供参考。

Xamarin.Android具有对等对象，用于引用Android JVM中已知的本机Java对象。它们实现了一个核心接口：

  namespace Android.Runtime 
 {
 public interface IJavaObject：IDisposable 
 {
 // JNI引用它正在包装的Java对象。 
 //也称为指向JVM对象的指针
 public IntPtr Handle {get;组; } 
 ... 
} 
} 
  

每当我们有一个具有 IJavaObject 的对象被继承，它将通过上面的JNI句柄保持强引用，以确保只要托管对象处于活动状态，它就一直保持活动状态。

以这种方式考虑：

IJavaObject - > IntPtr Handle - > Java对象

如下所示：

由Xamarin GC分配和收集 - > GC Root - > 由Android GC分配和收集

然后我们有一个GC进程Xamarin.Android：

GC运行时，你可以看到它会用一个弱引用代替一个强大的JNI句柄，然后调用Android GC w这将收集我们的Java对象。因此，将扫描 peers 以获取任何关系，以确保它们在JVM中镜像。这使得这些对象不会被过早地收集。

一旦发生这种情况，我们运行Android GC，并在完成时遍历对等对象并检查弱引用。

• 如果一个对象不见了，我们会在C＃端收集它
  
• 如果一个对象仍然存在，那么我们将弱引用改回到一个强大的JNI句柄中。因此，每次使用GC时都需要检查和更新这个图表在 peer 对象上运行。这就是为什么这些包装类型对象要慢得多，因为整个对象图必须从对象对象开始扫描。
  
  
  

  所以当有重要的对象图时，我们的 peer 对象使用，我们可以通过移动 peer 类之外的引用存储来帮助GC进程。这通常通过独立于对等体的 rooting 我们的引用完成。由于它不是作为字段存储的，因此GC不会尝试在对象图上进行关系漫游。



  如前所述，在您注意到很长的GC之前，这不是一个需要担心的大问题。您可以使用它作为解决方案。

  
  
  

  图片来源：Xamarin大学（ https://www.xamarin.com/university ）

  
  

  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.

  解决方案

  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)

  这篇关于Xamarin Android垃圾收集算法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！