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). This pull request has now been integrated. Changeset: c9281180 Author: Axel Boldt-Christmas <[email protected]> URL: https://git.openjdk.org/jdk/commit/c92811804f8c4db057c2680c835d9c55fdacecf9 Stats: 538 lines in 48 files changed: 161 ins; 222 del; 155 mod 8391176: Cleanup the markWord locking bits Co-authored-by: Roberto Castañeda Lozano <[email protected]> Reviewed-by: rcastanedalo, thartmann, stefank, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/32544
