RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable
Coleen Phillimore
coleenp at openjdk.org
Mon Mar 24 11:18:55 UTC 2025
On Tue, 18 Mar 2025 12:58:11 GMT, Coleen Phillimore <coleenp 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%
>
> 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.
runtime/Monitor/UseObjectMonitorTableTest.java#ExtremeDeflation
This test failed when I updated the monitor via CacheSetter when we don't succeed to get the lock.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2001001683
More information about the hotspot-runtime-dev
mailing list