On Wed, 26 Aug 2026 15:48:38 GMT, Axel Boldt-Christmas <[email protected]> wrote:
> The interface on oopDesc and the markWord w.r.t. the locking bits have grown > overtime the names do not reflect what they actually do, there are multiple > ways of asking for the same property. > > The properties `is_locked` and `is_unlocked` are misleading. As the answer > true of false does not necessarily reflect the locking state of the object. I > suggest we use a single terminology `is_fast_locked` to mean the locking bits > are locked using lightweight non-monitor locking and `is_neutral` to mean the > locking bits are in the prototype state. > > Using `is_fast_unlocked` could be an alternative to `is_neutral`, but > `is_neutral` captures the state better of being an object which is currently > not taking part in locking. However the name does not make it obvious that it > is referring to the locking state / mark state. Not 100% on this naming, and > how the comments and code which uses these constants in the MacroAssembler > should name and deal with this. > > Also cleaned up the C1 and C2 Valhalla header bits checks which were gated on > the locking bits. There is not more displaced header so conditionally > checking the prototype header in the Klass* is not needed. > > Testing (in progress): > * Tier 1-5 Oracle supported platforms > * GHA > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1783: > 1781: ldr(new_hdr, Address(obj, oopDesc::mark_offset_in_bytes())); > 1782: bic(new_hdr, new_hdr, markWord::lock_mask_in_place); // new header > (00) > 1783: orr(old_hdr, new_hdr, markWord::lock_neutral_value); // old > header (01) Please preserve the alignment to the comment above. Suggestion: orr(old_hdr, new_hdr, markWord::lock_neutral_value); // old header (01) src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1832: > 1830: ldr(old_hdr, Address(obj, oopDesc::mark_offset_in_bytes())); > 1831: bic(old_hdr, old_hdr, markWord::lock_mask_in_place); // old header > (00) > 1832: orr(new_hdr, old_hdr, markWord::lock_neutral_value); // new > header (01) Please preserve the alignment to the comment above. Suggestion: orr(new_hdr, old_hdr, markWord::lock_neutral_value); // new header (01) src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 4839: > 4837: if (!is_unlock) { > 4838: ldarx(tmp, obj, MacroAssembler::cmpxchgx_hint_acquire_lock()); > 4839: xori(tmp, tmp, markWord::lock_neutral_value); // flip unlocked bit Doing a `xori` using `lock_neutral_value` and then have a comment saying `flip unlocked bit` is utterly confusing. Before this change the comment made sense, but not any more. Please fix somehow. src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 4846: > 4844: andi_(R0, tmp, markWord::lock_mask_in_place); > 4845: bne(CR0, failed); // failed if old header doesn't contain > locked_value (which is 0) > 4846: ori(tmp, tmp, markWord::lock_neutral_value); // set unlocked bit Doing a `ori` using `lock_neutral_value` and then have a comment saying `set unlocked bit` is utterly confusing. Before this change the comment made sense, but not any more. Please fix somehow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32544#discussion_r3871459028 PR Review Comment: https://git.openjdk.org/jdk/pull/32544#discussion_r3871467787 PR Review Comment: https://git.openjdk.org/jdk/pull/32544#discussion_r3871498548 PR Review Comment: https://git.openjdk.org/jdk/pull/32544#discussion_r3871506871
