[lilliput-jdk21u:lilliput] RFR: 8316126: [Lilliput/JDK21] Cherry-pick: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental) [v3]

[Aleksey Shipilev]

On Wed, 13 Sep 2023 11:25:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 1353:
>> 
>>> 1351:         // range is OK as-is.
>>> 1352:         tj = ta = TypeAryPtr::RANGE;
>>> 1353:       } else if( offset == TypeOopPtr::klass_offset_in_bytes() ) {
>> 
>> Here and everywhere. Not sure why this is here. Why not in `oopDesc::`?
>
> The reason I did it this way is so that I can assert(!UCOH) in oopDesc::klass_offset_in_bytes(). The offset is used in C2 only as a sort of marker (to distinguish memory slice for the klass-word from other memory slices). It is not actually used as offset to load the Klass* - we load the whole mark-word and shift/mask/expand the Klass* from that, including the check for monitor.
> In the long run, as soon as the monitor-mapping in the header goes away, we could indeed use the oopDesc::klass_offset_in_bytes() everywhere - unless when we squeeze the narrowKlass in the header at a non-byte boundery, which is bound to happen once we go to 4-byte headers.

My concern is that it deviates from what we have in "mainline" version: https://builds.shipilev.net/patch-openjdk-lilliput/src/hotspot/share/opto/compile.cpp.sdiff.html -- which means we would always need to look for these discrepancies when backporting.

How does `openjdk/lilliput` achieve this?

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk21u/pull/5#discussion_r1325666572