RFR: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental) [v7]

[Aleksey Shipilev]

On Wed, 10 May 2023 19:16:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #10907, #13582 and #13779 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word, and dealing with (monitor-)locked objects. When the object is monitor-locked, we load the displaced mark-word from the monitor, and load the compressed Klass* from there. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded, and/or reach through to the monitor when the object is locked by a monitor.
>>  - The identity hash-code is narrowed to 25 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8. Due to alignment restrictions, array elements will still start at offset 16. #11044 will resolve that restriction and allow array elements to start at offset 12 (except for long, double and uncompressed oops, which are still required to start at an element-aligned offset).
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders.
>> 
>> Testing:
>>  (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests, and to avoid mismatches with CDS - see above.)
>>  - [x] tier1 (x86_64)
>>  - [x] tier2 (x86_64)
>>  - [x] tier3 (x86_64)
>>  - [ ] tier4 (x86_64)
>>  - [x] tier1 (aarch64)
>>  - [x] tier2 (aarch64)
>>  - [x] tier3 (aarch64)
>>  - [ ] tier4 (aarch64)
>>  - [ ] tier1 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier2 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier3 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier4 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier1 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier2 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier3 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier4 (aarch64) +UseCompactObjectHeaders
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'JDK-8305898' into JDK-8305895
>  - @shipilev review, round 2
>  - Fix build
>  - @shipilev comments, round 1
>  - Allow to resolve mark with LW locking
>  - Use new lightweight locking with compact headers
>  - Merge branch 'JDK-8305898' into JDK-8305895
>  - Imporve GetObjectSizeIntrinsicsTest
>  - Some GC fixes
>  - Add BaseOffsets test
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/39c33727...58046e58

> I have tried the same boot JDK with the mainline JDK code base, and it looks good. P.S. I also tried cross-compiling with this PR, and the building passed without failures.

OK, but this still points to incompatibility with boot/build JDK. The state of the source tree at this PR does not have any `STRING_TEMPLATES` symbol, it was added with JDK-8285932, so there is no way interim java.compiler in current PR references it, it must come from somewhere else. Do you have a self-built boot JDK that carries JDK-8285932? I'd suggest using a more stable JDK 20 as boot JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/13844#issuecomment-1543678637