RFR: 8373595: A new ObjectMonitorTable implementation [v8]

[Roman Kennke]

On Thu, 19 Feb 2026 10:11:30 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Me and Anton Artemov (@toxaart) investigated a quite large regression that occurred in Pet Clinic that happened if you turned on Compact Object Headers. It was found that a large portion of that regression could be attributed to not finding the monitor in the Object Monitor Cache, and because we couldn't access the Object Monitor Table from C2 generated code, we often had to take the slow path.
>> 
>> By making the object monitor cache larger and make it use the object's hash value as a key, we managed to mitigate the regression.
>> 
>> Erik Österlund (@fisk) took that idea and elevated it to the next level, which means that he rewrote the object monitor table code so that we can now search for an object in the global object monitor table from C2 generated code. I.e. from `C2_MacroAssembler::fast_lock()`. As in my and Anton's version, the key is the hash value from the object.
>> 
>> Erik also provided new barrier code needed for ZGC for x86 and aarch64. Roman Kennke (@rkennke) provided the same for Shenandoah, also for x86 and aarch64.
>> 
>> We decided to keep the Object Monitor Cache, since we found that for most programs (but not Pet Clinic) the monitor you are looking for is likely found in the first positions of the cache (it's sorted in most recently used order). However we decresed the size from 8 to 2 elements.
>> 
>> After running extensive performance tests we can say that this has improved the performance in many of them, not only mitigated the regression in Pet Clinic.
>> 
>> Tests are running okay tier1-7 on supported platforms.
>> 
>> The rest of the platforms (`ppc`, `riscv` and `s390`) have been smoke tested using QEMU.
>> I mainly used this test for smoke testing with QEMU: `-XX:+UnlockDiagnosticVMOptions -XX:+UseObjectMonitorTable ./test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java `
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8373595_new_object_monitor_table
>  - Second update for Axel
>  - Updated for RealFYang
>  - Updated for Andrew
>  - Updated for Axel
>  - Updated shared code after review comments
>  - Updated all platforms after review comments
>  - 8373595: A new ObjectMonitorTable implementation

This is great work!

Looks good to me, just a few nits on typos and a minor change in the Shenandoah barriers.

Thank you!

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 638:

> 636:   // which case we need to take the slow path.
> 637:   __ testb(gc_state, ShenandoahHeap::WEAK_ROOTS);
> 638:   __ jccb(Assembler::notZero, slowpath);

Suggestion:

  __ jcc(Assembler::notZero, slowpath);

src/hotspot/share/runtime/objectMonitorTable.cpp line 77:

> 75: //
> 76: // Both the new and (potentially several) old table(s) may exist at the same
> 77: // time. The newest is allays called the "current", and the older ones are

Suggestion:

// time. The newest is always called the "current", and the older ones are

src/hotspot/share/runtime/objectMonitorTable.cpp line 81:

> 79: //
> 80: // As soon as we have allocated and linked in the new "current" OMT, all new
> 81: // monitor pointers will be added to the new tale. Effectively making the

Suggestion:

// monitor pointers will be added to the new table. Effectively making the

src/hotspot/share/runtime/objectMonitorTable.cpp line 82:

> 80: // As soon as we have allocated and linked in the new "current" OMT, all new
> 81: // monitor pointers will be added to the new tale. Effectively making the
> 82: // atomic switch from "old current" to "new current" a linerization point.

Suggestion:

// atomic switch from "old current" to "new current" a linearization point.

src/hotspot/share/runtime/objectMonitorTable.cpp line 495:

> 493:           // In the current implementation the deflation thread drives
> 494:           // the rebuilding, and it will already have removed any entry
> 495:           // it has deflated. The assert is ony here to make sure.

Suggestion:

          // it has deflated. The assert is only here to make sure.

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29383#pullrequestreview-3826117135
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2828077160
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2828092491
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2828094229
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2828096230
PR Review Comment: https://git.openjdk.org/jdk/pull/29383#discussion_r2828110584