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

[Roman Kennke]

On Tue, 18 Mar 2025 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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.

I am not sure if I understand the problem. Why can't we do that? We successfully looked up the monitor from the OMCache, why can't we stick it in the BasicLock cache, to avoid having to look it up in the OMCache again? Whatever code would pull it out of the BasicLock and observe a deflating monitor might also pull it out of the OMCache and observe a deflating monitor, or is that not correct? I know that OMCache::get_monitor() filters deflating monitors, but that is not a guarantee that a monitor would not flip to deflating after that check? So ... the user of the monitor would always have to deal with deflation after it has pulled a monitor from any of the caches anyway?

If it is our contract that only successfully locked monitors go into the BasicLock cache, then we can't do that optimization, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2002563114