On Thu, 27 Aug 2026 14:53:39 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). > > Axel Boldt-Christmas has updated the pull request incrementally with one > additional commit since the last revision: > > Comment cleanups > 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 guess familiarity with "fast locking" schemes does affect how one interprets this. Given these are bits in the markword I expect them to indicate the markWord locking state, not necessarily the locking state of the object. That said I like the precision of `is_fast_locked`. I'm less keen on `lock_neutral` but I don't think any simple name here can convey "not fast locked and not associated with a Monitor" - any unfamiliar reader is going to have to go and look up what it means. Though it seems odd to have code that locks and unlocks, but does not refer to the unlocked state anymore. So while I'd be okay with keeping `is_unlocked` I won't fight against `lock_neutral`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32544#issuecomment-5447517330
