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

Aleksey Shipilev shade at openjdk.org
Thu Sep 14 09:44:04 UTC 2023


On Thu, 14 Sep 2023 09:37:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> 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?
>
>> 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?
> 
> It doesn't assert !UCOH in oopDesc::klass_offset_in_bytes(). Best approaches will be to either remove the assert and keep the 21 (and jdk upstream) stuff simpler, at the cost of loosing the assert, or bring over the C2 changes.

Lilliput JDK 17 does not do this either, it seems: https://builds.shipilev.net/patch-openjdk-lilliput-jdk17/src/hotspot/share/opto/compile.cpp.sdiff.html

So, I suggest we keep 21u close to both mainline and 17u by not asserting too, and using the usual `oopDesc::`?

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

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


More information about the lilliput-dev mailing list