RFR: 8315884: New Object to ObjectMonitor mapping [v6]

Axel Boldt-Christmas aboldtch at openjdk.org
Fri Jul 12 11:08:53 UTC 2024


On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> When you say 'This patch has been evaluated to be performance neutral when UseObjectMonitorTable is turned off (the default).' - what does the performance look like with +UOMT? How does it compare to -UOMT?

Most benchmarks are unaffected as they do not use any contended locking or wait/notify. Some see improvements and some show regressions. 

The most significant regressions are in `DaCapo-xalan` which is very sensitive to the timing of enter. It seems to rely quite heavily on how fast you can get to `ObjectMonitor::TrySpin` as well as the exact behaviour of this spinning. 

Then there are all the workloads which have not been tested in all these benchmark suites. The hope is to be able to incrementally iterate on the performance of the worst outliers.

> Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right?

My understanding (and shared hope) is that this is the ambition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2225341285


More information about the serviceability-dev mailing list