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

[Coleen Phillimore]

On Wed, 19 Mar 2025 07:05:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

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

Maybe this is okay.  My change that ran afoul of this test found the monitor in the first 32 entries of the ObjectSynchronizer::_in_use_list and filtered for deflating monitors also.  Then put the monitor it found in the OMCache. Since it didn't help performance, I backed this out of my change. It may be safer to put the monitor in the BasicLock field because it's cleared.  All this to say, I don't really know if this is right.

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

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