Java VM: Safepoint for RevokeBias

This article is an extract of my own learning during the work assignments. Intended audience is the regular Java Developers who want to understand the meaning of JVM safepoints and what is RevokeBias.

We had a JVM Crash (running JDK 1.7u45 Solaris SPARK). It generated a hs_err_pid#####.log (HotSpot Error Log) having error.

Internal Error (synchronizer.cpp:1550), pid=xxxxx, tid=yy
guarantee(!mid->is_busy()) failed: invariant

While trying to debug the issue and deciphering the HotSpot Error Log, I came across an entry in the Logs:

VM_Operation (0xfffffffb174fecc8): RevokeBias, mode: safepoint, requested by thread 0x00000001129e3800

Essentially above log statement implies that a thread (0x00000001129e3800) requested a VM Operation (RevokeBias) to be performed.

In my pursuit to understand above more, I found:

I am acquainted with the term "Stop The World" pause in JVM world. That is mostly associated with garbage collection cycles of JVM during which all the running threads are paused to free up the heap.

What I didn't know was that GC is just one VM operation which causes this, there are many more. Will discuss those later below.

What is a Safepoint?

In HotSpot JVM Stop-the-World pause mechanism is called safepoint. There are many VM operations for which the Stop-the-World is to be initiated. A safepoint means that all threads need to reach a certain point of execution before they are stopped.

1. VM waits for all the running threads to reach a safepoint.
2. Once all the threads have reached safepoint, they are blocked.
3. Afterwards, VM does some internal cleaning activity.
4. Then the VM operation is performed. 
5. Once VM is done with the operation execution, all threads are resumed.

Please read more on HotSpot Safepoints as How they work, - Safepoints in HotSpot JVM [By Alexey Ragozin].

Normally safepoints just work. Most of them, except GC ones, are extremely quick. Still, to debug and understand as how much time is being spent during safepoints OR which all VM operations are requesting the safepoints, we can use below JVM Options:

• -XX:+PrintGCApplicationStoppedTime – this will actually report pause time for all safepoints.
• -XX:+PrintSafepointStatistics –XX:PrintSafepointStatisticsCount=1 – this two options will force JVM to report reason and timings after each safepoint.

Please read more as how to read the output of these in logs - Debugging JVM Safepoint Pauses [By Christopher Berner].

VM Operations which cause safepoints?

Below are few VM operations which cause safepoint request:

• Garbage collection pauses
• Code deoptimization
• Flushing code cache
• Class redefinition (e.g. hot swap or instrumentation)
• Biased lock revocation (RevokeBias)
• EnableBiasLocking
• PrintThreads
• PrintJNI
• Various debug operation (e.g. deadlock check, stacktrace dump, heap dump, thread dump)

What is RevokeBias?

Since most Java objects are locked by at most one thread during their lifetime, that thread can bias an object toward itself. Once an Object is biased to a thread, that thread can subsequently lock and unlock the object without falling-back to other expensive techniques as atomic instructions or normal conventional locking.

Before Java 6, following JVM option needs to be enabled for Biased Locking:

-XX:+UseBiasedLocking Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines.

An object can be biased toward at most one thread at any given time. That thread is termed as "bias holding thread". If another thread tries to acquire a biased object, we need to revoke the bias from the original thread. This is accomplished by the VM Operation RevokeBias.

The effort involved in revocation is to coordinate the revoker and the revokee (the bias holding thread). Revocation can be implemented in various ways - signals, suspension, and safepoints to name a few. In current case we know now that it was done using safepoint (mode: safepoint).

To understand the concept of Bias Locking please read - Biased Locking in HotSpot [By David Dice].

Thanks for the read!!