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). ------------- Commit messages: - Fixup comments - Fold in CheckJNICalls and remove oopDesc interface - Move age comment - Rename to lock_neutral - 8391176: Cleanup the markWord locking bits Changes: https://git.openjdk.org/jdk/pull/32544/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32544&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8391176 Stats: 363 lines in 44 files changed: 16 ins; 203 del; 144 mod Patch: https://git.openjdk.org/jdk/pull/32544.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/32544/head:pull/32544 PR: https://git.openjdk.org/jdk/pull/32544
