Algorithm implementation of 5.HotSpot

1. Enumerate the root nodes

In the accessibility analysis, there are many nodes that can be used as GC roots, but many applications now have hundreds of megabytes in the method area, and if checked individually, efficiency becomes unacceptable.

Furthermore, accessibility analysis must be performed in a consistent snapshot-that is, the system freezes as it is during the entire analysis. Otherwise, if one side of the analysis, the system on one side of the dynamic table, the results will not be accurate. This results in the system GC having to pause all Java execution threads.

Currently the mainstream Java virtual machines are using the exact GC, so when the execution system is paused, there is no need to check all the execution context and global reference location without leaking, the virtual machine should have a way to know directly where the object reference is stored. In the hotspot implementation, a set of data structures called Oopmap is used to achieve this purpose. Oopmap will record what type of data is in the object's offset at the time the class is loaded, and in the JTI compilation process, the stack and register are referenced at a specific location. In this way, this information can be obtained directly when the GC is scanned.

2. Safety points

If the Oopmap content changes a lot of instructions, the hotspot does not generate oopmap for each instruction, only the information is recorded in a specific location, which becomes the "Safe Point" (SafePoint). When the program executes, it only pauses to start the GC when the security point is reached. Commands that typically have a longer run time can be selected as security points, such as method calls, loop jumps, exception jumps, and so on.

The next thing to consider is how to ensure that all threads "run" to a safe point in the GC. There are two scenarios: preemptive interrupt (preemptive suspension) and active interrupt (voluntary suspension).

Preemptive interrupts interrupt all threads, and if a thread is not on a security point, resume the thread and let it run to a secure point. There are few virtual machines in this way.

The active interrupt idea is that when you need to interrupt a thread, instead of directly manipulating the thread, a GC flag is set, and each thread polls the flag and interrupts its own suspend when needed. In this way, the polling flags are in place and the security points are coincident.

3. Security Zone

The security point mechanism guarantees that when the program executes, it will encounter a security point that can enter the GC in a not too long time, but when the program "does not execute", the program does not execute or allocates CPU time, the thread cannot respond to the JVM's interrupt request, and the JVM is apparently unlikely to wait for the thread to be allocated CPU time again.

A security zone is a piece of code that does not change the reference relationship. It is safe to start a GC anywhere in the region.

When a thread executes to a security zone code, it first identifies itself to the security zone, where the JVM initiates a GC and does not have to be labeled as a security zone. When the thread is leaving the security zone, check to see if the system has completed the root node enumeration, and if it completes, it will continue to wait until it receives a signal that it can safely leave the security zone.

Algorithm implementation of 5.HotSpot