RFR: 8320318: ObjectMonitor Responsible thread [v2]

Fredrik Bredberg fbredberg at openjdk.org
Fri Sep 13 13:19:27 UTC 2024


On Wed, 11 Sep 2024 12:04:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 482:
>> 
>>> 480:   // This is faster on Nehalem and AMD Shanghai/Barcelona.
>>> 481:   // See https://blogs.oracle.com/dave/entry/instruction_selection_for_volatile_fences
>>> 482:   lock(); addl(Address(rsp, 0), 0);
>> 
>> Since there's a membar above, do you need this lock/addl instructions?
>
> Well spotted @coleenp! No it's not needed. It was meant to be replaced by `membar(StoreLoad)`, which as @xmas92  wrote, does exactly that. Also, since I use `membar(StoreLoad)` in all other platforms, I wanted it to be consistent.

fixed

>> src/hotspot/share/runtime/objectMonitor.cpp line 353:
>> 
>>> 351: 
>>> 352: void ObjectMonitor::enter_for_with_contention_mark(JavaThread* locking_thread, ObjectMonitorContentionMark& contention_mark) {
>>> 353:   DEBUG_ONLY(bool success = ) ObjectMonitor::enterI_with_contention_mark(locking_thread, contention_mark);
>> 
>> This is kind of noisy with DEBUG_ONLY.  If you remove DEBUG_ONLY, does the windows compiler complain that you're not using the variable success in the product build?
>
> I don't know. I come from a planet where warnings was errors, and just brought along the old habit to my new planet. I'll check with the Windows compiler.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19454#discussion_r1758844955
PR Review Comment: https://git.openjdk.org/jdk/pull/19454#discussion_r1758850687


More information about the hotspot-dev mailing list