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

Axel Boldt-Christmas aboldtch at openjdk.org
Wed Apr 2 13:32:55 UTC 2025


On Wed, 2 Apr 2025 12:42:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> So is the issue that the 32 bit x86 code doesn't clear the BasicLock::monitor_cache before going slow path? I don't see the arm and s390 code doing that either. So the bug is that the quick-enter code will find a stale monitor?

s390 does (this code is used by interpreter and c1) https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/cpu/s390/macroAssembler_s390.cpp#L6361-L6365

Arm32 is protected inside the runtime with preprocessor macros https://github.com/openjdk/jdk/blob/fc5062a48767646414f9fd7e57a9370c766bda3e/src/hotspot/share/runtime/basicLock.inline.hpp#L43-L55

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

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


More information about the hotspot-runtime-dev mailing list