Safe point
JVM源码分析之安全点safepoint
http://www.jianshu.com/p/c79c5e02ebe6
聊聊JVM（九）理解进入safepoint时如何让Java线程全部阻塞
GC safe-point (or safepoint) and safe-region
Root references
An object is dead really means it is useless. Only the programmer knows if an object is useless or not. In order for the program to decide if an object is useless, we can use compiler analysis, reference counting, or reachability analysis.
Reachability analysis assumes an object is live as long as it is reachable by the mutator. If an object's reference is contained by a slot of the mutator's stack, it's directly reachable. Those objects reachable from reachable objects are also reachable. So the issue for reachability analysis is to find out the references that are directly reachable, which are root references. The set of root references is root set.
The mutator's context has the data that are directly reachable, so to get root set is to find object references in the context. The context of a mutator refers to its stack and its register file (and some other thread-specific data). Global data are also directly reachable.
Root set enumeration
Normally, if a GC uses reachability to determine an object's liveness, GC needs to get a consistent snapshot of the mutator's context, so as to enumerate the root references. This is true for both stop-the-world (STW) and concurrent GC (mostly). "Consistent" means the snapshot looks like taken at a single time point. A consistent snapshot of root references are necessary for correctness, otherwise some live objects might be lost. Then the question is how to get the consistent mutator's context snapshot.
To get the consistent snapshot, a simple way is that the mutator suspends its execution during the root references enumeration. The snapshot is also consistent if the root set does not change during the enumeration process.
When a mutator suspends its execution, it is not necessarily able to enumerate the root references in its context, unless it book-keeps the reference information in its context. That is, it should be able to tell which stack slots have references, and which registers hold references. If GC can accurately gets the information, it is called precise root set enumeration; or it's imprecise.
(For imprecise enumeration, GC has to use some heuristics to conservatively guess the references from the context. So the GC is called conservative GC. This essay only discusses precise enumeration.)
Harmony supports precise root set enumeration with GC safe-point and safe-region.
Safe-point (or safepoint)
In order to support precise enumeration, JIT compiler should do additional work, because only JIT knows exactly stack frame info and register contents. When JIT compiles a method, for every instruction, it can book-keep the root reference information in case the execution is suspended at that instruction.
But to remember the info for every instruction is too expensive. It requires substantial space to store the information. This is also unnecessary, because only a few instructions will have the chances to be the suspension points in real execution. JIT only needs to book-keep information for those instruction points -- they are called safe-points. Safe-point means it is a safe suspension point for root set enumeration.
Btw, the ability of a compiler to know exact stack slots' information is not universally available in all programming languages. Only safe languages have the ability. For example, C/C++ doesn't.
Mutator suspension
The question to safe-points is, how we can guarantee that the mutator is suspended at safe-point.
There are basically two kinds of approaches to suspend a mutator, preemptively or voluntarily. The preemptive approach is to suspend the mutator whenever GC needs to start a collection. If it finds the mutator is suspended at an unsafe point, it will resume the mutator, rolling it forward to a safe-point. This was implemented in ORP [1], the predecessor of Harmony. But currently almost no JVM takes this approach.
The approach used in Harmony is voluntary suspension. When GC wants to trigger a collection, it simply sets a flag; the mutators poll the flag periodically, and will suspend once they find the flag is set. Those polling points are safe-points. It's mostly JIT's responsibility to insert the pollings at proper positions. Sometimes VM also needs to have some polling points.
Polling point
So where are the right places for polling GC trigger event? As I discussed above, we do not want to have polling points for every instruction. For voluntary suspension, a more serious problem is the polling overhead. So the basic principles for polling point insertion are: Firstly, polling points should be frequent enough so that GC does not wait too long for a mutator to suspend, because other mutators might be waiting for GC to free the space in order to continue. Secondly, polling points should not be too frequent to introduce big runtime overhead.
The best result is to have only adequate polling points that are necessary and sufficient.
1. The mandatory polling points are the allocation sites. Allocation can trigger collection, so allocation site has to be a safe point.
2. Long-time execution are always associated with method call or loop. So call sites and loop back sites are also expected polling points.
Those are the sites for polling points in Harmony: allocation sites, call sites and loop back sites. Mostly the runtime overhead is smaller than 1%. Unfortunately we found safe-point alone is not sufficient.
Safe-region
Why can safe-point alone be not sufficient? The reason is we forgot one case of long time execution. We forgot it because it's actually not long time execution, but long time idle. There are situations when the application can not respond promptly to a GC trigger event, such as sleep, or being blocked in a system call. These operations are out of JVM's control. JVM can not respond to GC trigger event in that period. So we introduce safe-region to solve the problem.
Safe-region is the section of code that no references are mutated in it, then it is safe to enumerate roots at any points of that region. In other words, the safe region is a big extended safe-point.
In safe-point design, the mutator polling for GC event will respond if the event is triggered. It responds by setting a ready flag when it's sure to suspend. Then the GC can proceed with root set enumeration. This is a hand-shaking protocol.
Safe-region just follows this protocol. The mutator sets the ready flag when it enters a safe-region. Before it leaves the region, it checks if GC has finished its enumeration (or collection), and no longer needs the mutator under suspension state. If it's true, it goes ahead and leaves the region; otherwise, it suspends itself as in a safe-point.
In Harmony implementation, we insert suspend_enable and suspend_disable to delimit the scope of safe-region.
An object is dead really means it is useless. Only the programmer knows if an object is useless or not. In order for the program to decide if an object is useless, we can use compiler analysis, reference counting, or reachability analysis.
Reachability analysis assumes an object is live as long as it is reachable by the mutator. If an object's reference is contained by a slot of the mutator's stack, it's directly reachable. Those objects reachable from reachable objects are also reachable. So the issue for reachability analysis is to find out the references that are directly reachable, which are root references. The set of root references is root set.
The mutator's context has the data that are directly reachable, so to get root set is to find object references in the context. The context of a mutator refers to its stack and its register file (and some other thread-specific data). Global data are also directly reachable.
Root set enumeration
Normally, if a GC uses reachability to determine an object's liveness, GC needs to get a consistent snapshot of the mutator's context, so as to enumerate the root references. This is true for both stop-the-world (STW) and concurrent GC (mostly). "Consistent" means the snapshot looks like taken at a single time point. A consistent snapshot of root references are necessary for correctness, otherwise some live objects might be lost. Then the question is how to get the consistent mutator's context snapshot.
To get the consistent snapshot, a simple way is that the mutator suspends its execution during the root references enumeration. The snapshot is also consistent if the root set does not change during the enumeration process.
When a mutator suspends its execution, it is not necessarily able to enumerate the root references in its context, unless it book-keeps the reference information in its context. That is, it should be able to tell which stack slots have references, and which registers hold references. If GC can accurately gets the information, it is called precise root set enumeration; or it's imprecise.
(For imprecise enumeration, GC has to use some heuristics to conservatively guess the references from the context. So the GC is called conservative GC. This essay only discusses precise enumeration.)
Harmony supports precise root set enumeration with GC safe-point and safe-region.
Safe-point (or safepoint)
In order to support precise enumeration, JIT compiler should do additional work, because only JIT knows exactly stack frame info and register contents. When JIT compiles a method, for every instruction, it can book-keep the root reference information in case the execution is suspended at that instruction.
But to remember the info for every instruction is too expensive. It requires substantial space to store the information. This is also unnecessary, because only a few instructions will have the chances to be the suspension points in real execution. JIT only needs to book-keep information for those instruction points -- they are called safe-points. Safe-point means it is a safe suspension point for root set enumeration.
Btw, the ability of a compiler to know exact stack slots' information is not universally available in all programming languages. Only safe languages have the ability. For example, C/C++ doesn't.
Mutator suspension
The question to safe-points is, how we can guarantee that the mutator is suspended at safe-point.
There are basically two kinds of approaches to suspend a mutator, preemptively or voluntarily. The preemptive approach is to suspend the mutator whenever GC needs to start a collection. If it finds the mutator is suspended at an unsafe point, it will resume the mutator, rolling it forward to a safe-point. This was implemented in ORP [1], the predecessor of Harmony. But currently almost no JVM takes this approach.
The approach used in Harmony is voluntary suspension. When GC wants to trigger a collection, it simply sets a flag; the mutators poll the flag periodically, and will suspend once they find the flag is set. Those polling points are safe-points. It's mostly JIT's responsibility to insert the pollings at proper positions. Sometimes VM also needs to have some polling points.
Polling point
So where are the right places for polling GC trigger event? As I discussed above, we do not want to have polling points for every instruction. For voluntary suspension, a more serious problem is the polling overhead. So the basic principles for polling point insertion are: Firstly, polling points should be frequent enough so that GC does not wait too long for a mutator to suspend, because other mutators might be waiting for GC to free the space in order to continue. Secondly, polling points should not be too frequent to introduce big runtime overhead.
The best result is to have only adequate polling points that are necessary and sufficient.
1. The mandatory polling points are the allocation sites. Allocation can trigger collection, so allocation site has to be a safe point.
2. Long-time execution are always associated with method call or loop. So call sites and loop back sites are also expected polling points.
Those are the sites for polling points in Harmony: allocation sites, call sites and loop back sites. Mostly the runtime overhead is smaller than 1%. Unfortunately we found safe-point alone is not sufficient.
Safe-region
Why can safe-point alone be not sufficient? The reason is we forgot one case of long time execution. We forgot it because it's actually not long time execution, but long time idle. There are situations when the application can not respond promptly to a GC trigger event, such as sleep, or being blocked in a system call. These operations are out of JVM's control. JVM can not respond to GC trigger event in that period. So we introduce safe-region to solve the problem.
Safe-region is the section of code that no references are mutated in it, then it is safe to enumerate roots at any points of that region. In other words, the safe region is a big extended safe-point.
In safe-point design, the mutator polling for GC event will respond if the event is triggered. It responds by setting a ready flag when it's sure to suspend. Then the GC can proceed with root set enumeration. This is a hand-shaking protocol.
Safe-region just follows this protocol. The mutator sets the ready flag when it enters a safe-region. Before it leaves the region, it checks if GC has finished its enumeration (or collection), and no longer needs the mutator under suspension state. If it's true, it goes ahead and leaves the region; otherwise, it suspends itself as in a safe-point.
In Harmony implementation, we insert suspend_enable and suspend_disable to delimit the scope of safe-region.
