-
Enhancement
-
Resolution: Fixed
-
P4
-
17, 21, 22
-
b25
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8328080 | 21.0.4-oracle | Stefan Karlsson | P4 | Resolved | Fixed | b01 |
JDK-8328335 | 21.0.4 | Aleksey Shipilev | P4 | Resolved | Fixed | b01 |
There is yet another place where we call monitor deflation from outside of the monitor deflation thread. That place is the "final audit" part, which walks over monitors and performs verification and logging. Before the walk over the list of monitors we perform a monitor deflation pass to prune the system from "uninteresting" monitors.
I propose that we remove the monitor deflation from the final audit, and that we instead only visit "interesting" monitors (those that have an owner or "is busy"). After this change it's only the monitor deflation thread that performs monitor deflation. It is unclear to me if the final audit can actually interleave with the async monitor deflation, but this removal makes it easier to reason around monitor deflation since it is only one thread that is performing it.
- backported by
-
JDK-8328080 Remove monitor deflation from final audit
- Resolved
-
JDK-8328335 Remove monitor deflation from final audit
- Resolved
- blocks
-
JDK-8319137 release _object in ObjectMonitor dtor to avoid races
- Closed
- is blocked by
-
JDK-8318757 VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls
- Closed
- relates to
-
JDK-8320561 Inconsistency in monitorinflation logging
- Resolved
-
JDK-8325437 Safepoint polling in monitor deflation can cause massive logs
- Resolved
- links to
-
Commit openjdk/jdk21u-dev/d1af31b6
-
Commit openjdk/jdk/369bbecc
-
Review openjdk/jdk21u-dev/337
-
Review openjdk/jdk/16605