Android GC Garbage Collection Research Learning

Respect for the results of individual labor, reproduced please specify the source: http://blog.csdn.net/hnulwt/article/details/44903331
Many of the contents of this article speak of the JVM, and I would like to study the JVM to achieve the purpose of understanding DVM. For the sake of rigor, inquires a bit

Differences between JVM and DVM 1, Dalvik, and standard Java virtual machine (JVM)

The Dalvik is based on a register, and the JVM is stack-based. Register-based virtual machines for larger programs, it takes less time to compile.

2. The difference between Dalvik and Java bytecode

The Dalvik executes. DEX-formatted bytecode, while the JVM executes the. Class byte-code. After the Android program is compiled, the. class file is produced, and the R.class is generated through the AAPT tool, and then the DX tool processes the. dex file, and the final resource file and the. dex file are packaged into an. apk file.

3. The difference between Dalvik and Java operating environment

Dalvik mainly includes the completion of object lifecycle management, stack management, thread management, security and exception management, as well as garbage collection and other important functions.
Dalvik is responsible for process isolation and thread management, and each Android application will have a standalone Dalvik virtual machine instance at the bottom, and its code can be executed under the virtual machine interpretation.

Through the above can be seen, these differences do not affect the DVM-GC-related learning, so I study the JVM related garbage collection mechanism to learn about the Android GC related content, if there is anything wrong in the text, the trouble points out that common learning, common progress.

Roughly speaking: GC (garbage Collection) dynamically reclaims memory space occupied by objects without any references. The GC determines whether to collect the object by determining whether the object is referenced by the active object.
But to understand these words, we may need to know the following.

JVM Memory model

Young Generation

Eden + S0 + S1 in the diagram
Eden: Storing new objects
Survivor Space:s0, S1 has two, stores the object that survives after each garbage collection
(1) Most new objects are located in the Eden area.
(2) When the Eden area is filled with objects, the minor GC is executed. and transfer all surviving objects to one of the survivor areas.
(3) Minor GC also checks for surviving objects and transfers them to another survivor area. In this way, there will always be an empty survivor area for a period of time.

Old Generation

The old Memory in the figure mainly holds the objects that the application survives in the medium and long term, and the surviving objects after multiple minor GC. Garbage collection is usually done in the old years when memory is full. Garbage collection in the old age is called Major GC. Major GC will take more time.

Permanent Generation:

Store the method area with the class information to load, static variables, final type constants, properties, and method information.

Two garbage collection mechanisms used by the JVM for the Cenozoic and the old generation respectively? New generation of GC:

The new generation usually has a shorter survival time, so the so-called copying algorithm is used to retrieve the surviving object based on the copying algorithm, and copy it into a completely unused space, corresponding to the Cenozoic, which is copy between Eden and Fromspace or Tospace. The Cenozoic uses a free pointer to control the GC trigger, the pointer keeps the last allocated object in the Cenozoic interval, and when a new object is allocated memory, it is used to check if the space is sufficient and not enough to trigger the GC. When objects are continuously allocated, the objects gradually go from Eden to Survivor, and finally to the old generation.

GC for old generation:

The old generation and the new generation, the object survival time is longer, more stable, so the mark (Mark) algorithm for recycling, so-called Mark is to scan out the surviving objects, and then to reclaim unmarked objects, after recycling the empty space is either merged, or marked out for the next allocation, The bottom line is to reduce the loss of efficiency caused by memory fragmentation.

How do I tell if an object can be recycled?

Two common methods are reference counts and object reference traversal.

(1) Reference count collector

The reference count is an early policy in the garbage collector. In this approach, each object (not a reference) in the heap has a reference count. When an object is created, and the object is assigned to a variable, the variable count is set to 1. When any other variable is assigned a reference to this object, the count is added 1 (a = B, then B refers to object +1), but the reference count of the object is reduced by 1 when a reference to an object exceeds the life cycle or is set to a new value. Any object with a reference count of 0 can be garbage collected. When an object is garbage collected, it refers to any object count minus 1.

Advantage: The reference counting collector can be executed very quickly, interwoven in the program running. It is advantageous to the real-time environment that the program is not interrupted for a long time.

Disadvantage: cannot detect a circular reference. If the parent object has a reference to a child object, the child object in turn references the parent object. In this way, their reference count will never be 0.

(2) Tracking collector

Most JVMs now use object reference traversal. Object reference traversal starts with a set of objects and recursively determines the reachable (reachable) object along each link on the entire object graph. If an object cannot arrive from one (at least one) of these root objects, it is garbage collected. During the object traversal phase, the GC must remember which objects can be reached in order to delete the Unreachable object, which is known as the markup (marking) object.

Next, the GC wants to delete the unreachable object. When deleted, some GC simply scans the stack, removes unmarked unmarked objects, and frees their memory to generate new objects, called Purge (sweeping). The problem with this approach is that memory is broken into small chunks, which are not sufficient for new objects, but are very large in combination. As a result, many GCs can reorganize objects in memory and compress (compact) to make available space.

To do this, the GC needs to stop other active activities. This approach means that all application-related work is stopped and only the GC is running. As a result, many miscellaneous requests are added and subtracted during the response. In addition, more complex GCS are constantly increasing or running concurrently to reduce or eliminate the interruption of the application. Some GC uses a single thread to do the work, while others use multithreading to increase efficiency.

Reason for GC (log interpretation)

In the official documentation, the GC reason has the following 5:

Gc_concurrenta Concurrent Garbage Collection thatFrees up memory asYour heap Begins toFill up. Gc_for_malloca garbage collection caused because your app attempted toAllocate memory when your heap is already full, so theSystem had toStop your App andReclaim memory. Gc_hprof_dump_heapa Garbage Collection thatOccurs when to create an HPROFfile  toAnalyze your heap. Gc_explicitan explicit garbage collection, such asWhen the call GC () (which should avoid calling andInstead trust theGarbage collector to RunWhen needed). Gc_external_allocthis happens only onAPI levelTen  andLower (newer versions allocate everythinginch  theDalvik heap). A Garbage Collection forExternally allocated memory (such as  thePixel data storedinchNative memoryorNIO byte buffers).

Gc_concurrent and Gc_for_malloc are common GC reasons. You can view it on Logcat by running the program.
Gc_concurrent garbage Collection when the heap is full
Gc_for_malloc This is the "Stop the World" event, because all application threads will stop until the operation is complete. When the heap is full, you apply for allocating memory to trigger the GC for this reason.

Gc_hprof_dump_heap
The GC reason when we created the Hprof file to analyze the heap memory.

Gc_explicit
When we show the call to the System.GC () method, the log will appear.

Gc_external_alloc
This only appears in API 10 and below, and we don't need to pay attention.

The article is partly referenced from:
Original link: Journaldev translation: Importnew.com-jin Lin Translations Link: http://www.importnew.com/14086.html
Detailed introduction to Java garbage collection mechanism: http://www.cnblogs.com/laoyangHJ/articles/java_gc.html
Baidu Encyclopedia: http://baike.baidu.com/view/1551869.htm

Android GC Garbage Collection Research Learning