I heard this question on an interview and couldn't provide an answer. Later I searched thru the internet and still didn't find an answer. Can anybody tell me how JVM stops threads during stop-the-world pause when collecting garbage and how it run them again.
Asked
Active
Viewed 2,876 times
20
-
This really depends on JVM implementation. Simple JVMs, like jamvm for instance, that do bytecode interpretation (no JITing), can simply lock the memory pool with a mutex, so no interpretation threads can affect it during GC phase (since they are blocked on that mutex). – Archie May 15 '13 at 09:22
1 Answers
17
For HotSpot and OpenJDK at least, the JVM uses safe points to stop the application's flow in each thread, either introduced in the JITed code or by changing the bytecode mappings for interpreted code (see this post by Alexey Ragozin for more details).
See also this answer by Gil Tene on why safepointing can be an additional issue when dealing with stop-the-world pauses.
Here are more details (as I understand them, I don't claim to be an expert) on the safepointing mechanism in Hotspot/OpenJDK (see for example safepoint.cpp, line 154), based on the above resources, and probably on some articles by Cliff Click on the Azul Systems blog (which seems to have disappeared from the site).
Reaching the safepoint
The JVM needs to get control of the flow from the application, so it depends on the current state of the threads:
Blocked
The JVM already has control of that thread.
Running interpreted code
The interpreter goes into a mode (by swapping its dispatch table) where each bytecode evaluation will be preceded by a safepoint check.
Running native code (JNI)
JNI code runs in a safepoint and can continue running, unless it calls back into Java or calls some specific JVM methods, at which point it may be stopped to prevent leaving the safepoint (thanks Nitsan for the comments).
Running compiled code
The JVM makes a specific memory page (the Safepoint Polling page) unreadable, which makes the periodic reads of that page (inserted into the compiled code by the JIT compiler) fail and go to a JVM handler.
Running in the VM or transitioning states (in the VM also)
The flow goes through the safepoint check at some point anyway, so the VM waits for it.
Stopping at the safepoint
Once a thread is at the safepoint, controlled by the JVM, the JVM simply blocks it from exiting. When all threads have been stopped (i.e. the world is stopped), the JVM can do the garbage collection then release all the threads which resume execution.
For much more details, you can go read this blog post on safepoints written by Nitsan Wakart in the meantime (which itself has even more references).
Community
- 1
- 1
Frank Pavageau
- 11,477
- 1
- 43
- 53
-
I knew that JVM can stop thread in safe point only and when thread is in a safe point it check some flag that will indicate that thread should stop here. In this post I was trying to understand what mechanism JVM use to stop thread. From the Alexey post I understood that it's a too complex task but he didn't told about it in details. Frank, could you point me another article that describes problem in more details way? Thanks in advance! – Mirian May 16 '13 at 08:12
-
@Mirian Do you want to understand how the JVM makes all threads _reach_ the safepoint, or how it stops them _once they are at the safepoint_? – Frank Pavageau May 16 '13 at 12:55
-
-
JNI code runs inside a safespoint, so in fact does not need stopping. If it calls back into Java code or uses certain JVM methods it may be stopped as it will not be able to leave safepoint. – Nitsan Wakart Jan 06 '15 at 14:33
-
The "Stopping at a safepoint" section is not correct. Certainly the safepoint poll happens before the thread goes into a safepoint, but a safepoint is not a memory barrier. – Nitsan Wakart Jan 06 '15 at 14:35
-
Strictly speaking, I didn't write that the safepoint is a memory barrier. But I'll try rewording it, as well as adding your points on JNI. – Frank Pavageau Jan 07 '15 at 12:53
-
@NitsanWakart hey, I actually remembered to edit the answer based on your comments. I hope it's more precise (and correct) now. – Frank Pavageau Feb 02 '16 at 09:44
-
@FrankPavageau see a more complete answer in this blog post: http://psy-lob-saw.blogspot.co.za/2015/12/safepoints.html – Nitsan Wakart Feb 02 '16 at 14:46
-
@FrankPavageau Where do you get this? "The JVM uses a memory barrier to block the threads (during the safepoint poll): the threads then enter the safepoint and wait, enforcing that the safepoint operation happens before the threads resume execution. It's the same mechanism used to provide ordering guarantees in the Java Memory Model introduced in Java 5, for stuff such as volatile fields for example." The JVM makes the page protected -> SP poll results in a page fault which has a special handler that tidies up and blocks the thread. – Nitsan Wakart Feb 02 '16 at 14:52
-
1@NitsanWakart I'd say it was a misguided summary of the "How safepoints work" paragraph in Alexey Ragozin's blog post (first link). I'll just simplify this. – Frank Pavageau Feb 03 '16 at 08:54
-
in my opinion, JVM compiles java code(.java file) to byte code( .class file) and interpreted the byte code to machine code to actually run the program. I think that there is no safe point when JVM is compiling the java code. So I am confused by the meaning of "Running interpreted code" and "Running compiled code" and I think thank JVM only run the interpreted code, could you please show me the actual difference between them? – Boli-CS May 16 '16 at 06:09
-
@Boli-CS `javac` (which runs in a JVM) compiles the Java code to bytecode, `java` (another JVM) runs the bytecode, first in interpreted mode, then (with the server VM and default settings, once a method has been called 10000 times) compiles it to native code and runs that instead, resulting in faster execution (because it's native **and** optimized at the same time). There's ample literature on that, I'm not going to expand on it in the comments of an unrelated subject. – Frank Pavageau May 16 '16 at 12:07