On Thu, 27 Aug 2026 13:03:33 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: > > Removed the assert, we have other checks for inconsistent locking I am looking at this change as well diff --git a/src/hotspot/share/oops/markWord.hpp b/src/hotspot/share/oops/markWord.hpp index 893e3dc80bf..61d7011b98c 100644 --- a/src/hotspot/share/oops/markWord.hpp +++ b/src/hotspot/share/oops/markWord.hpp @@ -181,8 +181,8 @@ class markWord { static const uintptr_t monitor_value = 2; static const uintptr_t marked_value = 3; - static const uintptr_t inline_type_pattern = inline_type_bit_in_place | lock_neutral_value; - static const uintptr_t inline_type_pattern_mask = inline_type_bit_in_place | lock_mask_in_place; + static const uintptr_t inline_type_pattern = inline_type_bit_in_place; + static const uintptr_t inline_type_pattern_mask = inline_type_bit_in_place; static const uintptr_t no_hash = 0 ; // no hash value assigned static const uintptr_t no_hash_in_place = (uintptr_t)no_hash << hash_shift; @@ -194,6 +194,7 @@ class markWord { static markWord zero() { return markWord(uintptr_t(0)); } bool is_inline_type() const { + precond(!is_marked()); #ifdef _LP64 // 64 bit encodings only return (mask_bits(value(), inline_type_pattern_mask) == inline_type_pattern); #else Because I do not think we need this filter anymore. It only currently protects against marked values, which users of these inline type bits check should not use. Also looking at removing the ideal pass which recognises the old phi node for the mark + prototype header, I think this was the only use for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32544#issuecomment-5440722639
