RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v3]

[Coleen Phillimore]

On Wed, 26 Mar 2025 07:54:43 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%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include objectMonitor.inline.hpp

Sorry for the delay, the performance testing took a while.  I ran the old and new DaCapo benchmarks on a version of the VM with quick_enter calling try_spin rather than try_lock to see if the try_spin had any negative effects without UseObjectMonitorTable.  I ran on our standard linux-x64 and linux-aarch64 machines.  It had no significant effect on performance except a 3.7 improvement for old DaCapo xalan on linux-aarch64.

I think this should be checked in with RFEs for further improvements.  I had a couple of cleanups in this area that I'm waiting for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2769116156