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

I removed the Phi + And + Prototype header shape recognition that was removed 
in this simplification 230b3297114f7e3b7adfc7de6e05808f36110c63. I guess this 
is the correct thing to do, even if that recognition and optimisation could be 
used in the future if we decide to use the prototype again. 

I think I correctly preserved the normal "and all the marks and check the 
header/mark bit mask" ideal folding. But would be nice to get some C2 engineer 
to look at these C2 changes.

Going to run more targeted tests here as well.

Also curious if we have any Valhalla specific benchmarks where we can see if 
there is some measurable difference now that we only check the header bits 
rather than sometimes dispatch to the Klass metadata.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/32544#issuecomment-5452109231

Reply via email to