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

Axel Boldt-Christmas aboldtch at openjdk.org
Tue Apr 1 19:53:23 UTC 2025


On Tue, 1 Apr 2025 16:00:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > No more concerns about the setting of BasicLock cache in enter?
> > 
> > 
> > No, I think the bug that I ran into wasn't this, so no more concerns.
> 
> Ok, good. @xmas92 also had concerns about doing that BL caching in enter that sounded like he wanted to hold this part back for now.

I think there is a problem with quick_enter on 32bit x86. As it may fast lock successfully without clearing the cache, which iirc can be garbage (or read it as a monitor later). I would either make 32bit x86 return nullptr from `BasicLock::object_monitor_cache` or just add the `CacheSetter` / `if (UseObjectMonitorTable) { lock->clear_object_monitor_cache() }` in the `#ifndef _LP64` block. This is because the interpreter and C1 does not use `MacroAssembler::lightweight_lock` because of limited availability of registers and simply called into the VM. That is why the CacheSetter was introduced in quick enter.

For all other platforms which uses `BasicLock::object_monitor_cache` have clear the cache in interpreter/ C1 and C2 (have not checked recently, but iirc Graal does the same thing as C2 here)

Not sure what the state is w.r.t. 32bit x86 being deprecated for removal, but may just having `ObjectMonitor* BasicLock::object_monitor_cache()` return nullptr on 32 bit is the most straightforward solution here.

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

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


More information about the hotspot-runtime-dev mailing list