It's not a high-priority one, since the problem rarely appears in real-life applications.Ī new JVM flag appeared in JDK 8u92 to work around the issue. Here is the related JVM bug: JDK-5014723. This issue has been known for a long time. If a stop-the-world pause is requested while the method is running, all other threads will also wait. So, if this method runs in compiled mode, JVM cannot stop it until the method completes. InsertionSort has two very long nested counted loops, and it looks like JVM has eliminated safepoint checks inside them. This is the second thread of the Executor's pool, which should run insertionSort algorithm. Yes, it printed that the thread pool-1-thread-2 could not stop in 1000 ms. # SafepointSynchronize::begin: (End of list) # SafepointSynchronize::begin: Threads which did not reach the safepoint: # SafepointSynchronize::begin: Timed out while spinning to reach a safepoint. # SafepointSynchronize::begin: Timeout detected: This should print a debug message whenever VM fails to reach a safepoint in 1000 ms. Let's get back to our test and check if safepoints are reached in time.Īdd -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=1000 JVM options. loops with an integer counter that are known to have finite number of iterations. One such optimization is to eliminate safepoint checks in counted loops, i.e. That's why JIT compiler tries to reduce number of safepoints where possible. The safepoint checks are relatively cheap in terms of perfomance, but not free. In JIT-compiled code the safepoints are usually placed at method exits and at backward branches, i.e. But Java threads could not be stopped at any arbitrary point, they can pause only at certain places called safepoints. BackgroundĬertain VM operations (GC, Deoptimization, Thread dump and some other) are executed at stop-the-world pauses when no Java threads are running.

The delay means that VM wasn't able to reach a safepoint in short time. The fact that a thread dump hasn't appeared immediately indicates that the problem is not in Java code, but is somehow related to JVM.

This is a very interesting question: a simple Java test reveals a non-trivial problem deep inside JVM.

TL DR HotSpot JIT optimization to eliminate safepoint checks in counted loops played a sick joke.

Jar launcher windows