RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable

[Coleen Phillimore]

On Tue, 18 Mar 2025 12:41:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
> - Some small code shufflings.
> 
> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
> without-OMT: 773.3 ms
> with-OMT: 797.28 ms
> 
> That is still a regression of ~3%

I had a couple of comments but it's similar to what I have.  I didn't use the BasicLock though for quick_enter and this hit variable is a bit confusing why it's there.  I'm going to ask Eric to run our benchmarks on my similar version.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 759:

> 757:     }
> 758:   } else {
> 759:     monitor = ObjectSynchronizer::read_monitor(current, object, mark);

This can just be read_monitor(mark).

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1236:

> 1234: 
> 1235:     if (UseObjectMonitorTable) {
> 1236:       lock->set_object_monitor_cache(monitor);

I hit a bug where this was a deflating monitor so I don't think we can do this.

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

PR Review: https://git.openjdk.org/jdk/pull/24098#pullrequestreview-2694424229
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2000986680
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2000989920