JEP draft: Concurrent Monitor Deflation

AuthorsCarsten Varming <>, Roman Kennke <>,
OwnerDaniel Daugherty
StatusClosed / Withdrawn
Componenthotspot / runtime
Discussionhotspot dash runtime dash dev at openjdk dot java dot net
Reviewed byDavid Holmes, Mikael Vidstedt
Created2017/07/06 02:49
Updated2020/05/29 00:04


Deflate idle ObjectMonitors concurrently with Java thread execution in order to reduce safepoint pause times.



Reducing safepoint pause times reduces system latency and is a "good thing" (TM) for advanced projects like ZGC.

Success Metrics


ObjectMonitors are associated with Java objects on an as-needed basis; this is called "inflation". Operations like Object.wait() or contended synchronization cause inflation. When an ObjectMonitor becomes idle, it is eligible for "deflation". Inflation and deflation of ObjectMonitors are invisible to a Java program.

ObjectMonitors are generally managed on a Java thread's in-use or free list; they can also be managed on a global in-use or free list. The process of deflation moves an ObjectMonitor from an in-use list to the global free list.

In the current system, idle ObjectMonitors are deflated at a safepoint and the time that it takes to do that work contributes to a safepoint's pause time. Over the years work has been done to reduce the total time it takes to deflate ObjectMonitors:

The next step in the evolution of the ObjectMonitor subsystem is to deflate idle ObjectMonitors concurrently with Java thread execution instead of doing that work at a safepoint. Of course, deflating an idle ObjectMonitor while not being at a safepoint changes some of the invariants in the ObjectMonitor subsystem and we have to make some adjustments. It also introduces new race conditions that did not previously exist so we also have to account for those.

As you can imagine, there are lots of details in a project that changes a core subsystem like ObjectMonitors so an OpenJDK wiki has been created that covers all the details:


Risks and Assumptions

The ObjectMonitor subsystem is a critical part of the Java platform. If we break it, then the system can come to a grinding halt, hang or cause data corruption due to broken synchronization. Sounds scary!

Fortunately, like other key subsystems in the Java platform, "just" running the tests reduces the risk of breaking something. We have been running Mach5 Tier1-Tier8 tests for most of the year plus duration of this project. We have requested special test runs from other projects like ZGC. We have asked for test runs from folks outside of Oracle. Due diligence has been a core theme for this project.