On Fri, 28 Aug 2026 06:36:04 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: > > Alignment Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/32544#pullrequestreview-5048755290
