RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable [v2]
Roman Kennke
rkennke at openjdk.org
Wed Mar 26 07:29:06 UTC 2025
On Tue, 25 Mar 2025 18:37:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> 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.
>
> Looks like from GHA, this also fails the same test. I think you should remove this optimization since I don't think it helps any.
'it does not help any' is not correct. The point of this PR is to put the OM in the BasicLock cache early, even if it does not succeed to enter, so that slower paths can pick it up from there. Also, simply removing this particular line would not change anything, because we put the OM in the BasicLock cache in the C2 fast-path in the same way.
I think the BasicLock OM cache should be treated the same way as the thread's OMCache. The BasicLock cache is basically the L1 cache, while the OMCache is the L2 cache. And just like the OMCache lookup, we should clear the BasicLock cache when we observe a deflating monitor. This fixes the failing test.
@xmas92 should also look at this.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2013529352
More information about the hotspot-runtime-dev
mailing list