JDK-8348833 : Remove ObjectMonitor perf counters
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 25
  • Submitted: 2025-01-28
  • Updated: 2025-03-24
  • Resolved: 2025-03-24
Related Reports
CSR :  
JDK-8348829 - Remove ObjectMonitor perf counters
Relates :  
JDK-8351142 - Add JFR monitor deflation and statistics events
Relates :  
JDK-8351187 - Add JFR monitor notification event
Relates :  
JDK-8351146 - JFR: JavaMonitorInflate event should default to no threshold and be disabled
Description
Summary
-------

Remove ObjectMonitor performance counters, exposed in `sun.rt._sync*` namespace.

Problem
-------

There is a bunch of ObjectMonitor performance counters:

```
PerfCounter * ObjectMonitor::_sync_ContendedLockAttempts = nullptr;
PerfCounter * ObjectMonitor::_sync_FutileWakeups = nullptr;
PerfCounter * ObjectMonitor::_sync_Parks = nullptr;
PerfCounter * ObjectMonitor::_sync_Notifications = nullptr;
PerfCounter * ObjectMonitor::_sync_Inflations = nullptr;
PerfCounter * ObjectMonitor::_sync_Deflations = nullptr;
PerfLongVariable * ObjectMonitor::_sync_MonExtant = nullptr; 
```

They seem to be seldom used, and their continued maintenance comes with at least two problems, both of which come down to intrinsic race against VM shutdown, see JDK-8049304 and JDK-8348402. Additionally, these get updated on locking paths, and attempts to do extra things, including synchronization, might obscure some of the bugs.

Some of these counters are covered by related JFR events:

 - `_sync_ContendedLockAttempts`: covered by existing `JavaMonitorEnter` event
 - `_sync_FutileWakeups`: not covered, we think this is unnecessary to track
 - `_sync_Parks`: covered by existing `JavaMonitorWait` event
 - `_sync_Notifications`: covered by new `JavaMonitorNotify` event (JDK-8351187)
 - `_sync_Inflations`: covered by existing `JavaMonitorInflate` event
 - `_sync_Deflations`: covered by new `JavaMonitorDeflate` event (JDK-8351142)
 - `_sync_MonExtant`: covered by new `JavaMonitorStatistics` event (JDK-8351142)

These counters are also accessible through internal APIs or jcmd:

```
% jcmd 8090 PerfCounter.print | grep _sync
sun.rt._sync_ContendedLockAttempts=10045275
sun.rt._sync_Deflations=222972
sun.rt._sync_FutileWakeups=4184363
sun.rt._sync_Inflations=222991
sun.rt._sync_MonExtant=7
sun.rt._sync_Notifications=1521211
sun.rt._sync_Parks=7667155
```

Solution
--------

The solution is to remove these counters.

Specification
-------------

All counters in `sun.rt._sync*` would be gone, see related PR:
https://github.com/openjdk/jdk/pull/23326
Comments
Moving to Approved.
24-03-2025
I agree this can be Finalized
19-03-2025
All new JFR events are now in mainline, so I wrote up JDK-8349549 release note highlighting the suggested mapping. Also updated CSR body with this mapping. I think we are now fully covered and can proceed.
18-03-2025
I've added a Release Note subtask to JDK-8348829.
03-03-2025
Will Approve after Finalization contingent on a release note being written.
04-02-2025
If these counters are not exposed through any of the tools then I have less concern about their use and our need to continue to support them. I would suggest however a release note that explains that the counters have been removed and what equivalent JFR event(s) can be used to obtain the same kind of information.
04-02-2025
Moving to Provisional, not Approved. [~dholmes], do you have any additional concerns about this CSR?
03-02-2025
From email with [~poonam]: Performance Counters are used by several tools, for example, jps, jstat, VisualGC, and I think even by JConsole. The jstat tool, even though experimental and unsupported (https://docs.oracle.com/en/java/javase/17/docs/specs/man/jstat.html), is used by customers; we have had reports from customers against this tool. VisualGC is available as a plugin to the VisualVM: https://visualvm.github.io/plugins.html. Though we haven’t heard many customers using it, I found a few articles on the web describing how to use VisualGC plugin with VisualVM. So, if you are planning to remove any of the perf counters, it would be good to make that those counters are not being exposed through any of these tools. From the jstat documentation, I don’t think it exposes any of the ObjectMonitor related information. Hope this helps!
31-01-2025
> I suspect it is correct that perf counters are not used that much these days. But then we should be considering removing them all. There may be other perf counters that are used for other reasons. These ObjectMonitor ones were mostly to track internal performance information that would be most useful to HotSpot engineers who understand the implementation details, so we should just these counters for now. If we determine that the other counters aren't useful separately, we can have another effort to deprecate and/or remove them also.
30-01-2025
Like all statistics these perf counters are useful for what they were designed. They track specific synchronization "events" because in the past these were needed to analyse performance issues in the sync code. However, with new locking code (like lockstacks) these events are unlikely to be that useful on their own as we would need new statistics specific to the new locking code - did we add any perf counters with that new code? Does JFR really capture the same information? Did we add new JFR events with the new locking code? I suspect it is correct that perf counters are not used that much these days. But then we should be considering removing them all.
29-01-2025
There are better ways to get this information with JFR. There are events that should be changed to 5ms and give more information. <event name="jdk.JavaMonitorEnter"> <setting name="enabled">true</setting> <setting name="stackTrace">true</setting> <setting name="threshold" control="locking-threshold">20 ms</setting> </event> <event name="jdk.JavaMonitorWait"> <setting name="enabled">true</setting> <setting name="stackTrace">true</setting> <setting name="threshold" control="locking-threshold">20 ms</setting> </event> <event name="jdk.JavaMonitorInflate"> <setting name="enabled">false</setting> <setting name="stackTrace">true</setting> <setting name="threshold" control="locking-threshold">20 ms</setting> </event> There's little or poor out of date documentation for JFR but changing these to 5ms and doing jfr help view, there's a view called contention-by-site that I found useful. Also see [~egahlin] blog at https://egahlin.github.io/. In doing recent performance analysis on our locking code, I didn't find the perf counters useful at all. Removing them will improve the code.
28-01-2025