8305895: Implement JEP 450: Compact Object Headers (Experimental)

[rkennke]

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 purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
• 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 8305898: Alternative self-forwarding mechanism #20603 and 8305896: Alternative full GC forwarding #20605 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. 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.
• The identity hash-code is temporarily narrowed to 25 bits. As soon as we get Tiny Class-Pointers (planned before the JEP can be integrated, and to be opened for review soon), we will widen the hash-bits back to 31 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.
• 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. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
• Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (or at least I could not find it), and also I fear that doing so could mess with optimizations. This may be useful to revisit. OTOH, the approach that I have taken works and is similar to DecodeNKlass and similar instructions.

Testing:
(+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests.)
The below testing has been run many times, but not with this exact base version of the JDK. I want to hold off the full testing until we also have the Tiny Class-Pointers PR lined-up, and test with that.

• tier1 (x86_64)
• tier2 (x86_64)
• tier3 (x86_64)
• tier4 (x86_64)
• tier1 (aarch64)
• tier2 (aarch64)
• 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
• Running as a backport in production since >1 year.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a JEP request to be targeted
• Change requires CSR request JDK-8306000 to be approved
• Change must be properly reviewed (3 reviews required, with at least 1 Reviewer, 2 Authors)

Issues

• JDK-8305895: Implement JEP 450: Compact Object Headers (Experimental) (Enhancement - P4)
• JDK-8294992: JEP 450: Compact Object Headers (Experimental) (JEP)
• JDK-8306000: Add experimental -XX:+UseCompactObjectHeaders flag (CSR)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer) 🔄 Re-review required (review applies to 525a8efc)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20640/head:pull/20640
$ git checkout pull/20640

Update a local copy of the PR:
$ git checkout pull/20640
$ git pull https://git.openjdk.org/jdk.git pull/20640/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20640

View PR using the GUI difftool:
$ git pr show -t 20640

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20640.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back rkennke! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@rkennke The following labels will be automatically applied to this pull request:

• build
• core-libs
• graal
• hotspot
• serviceability
• shenandoah

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[AlanBateman]

/label remove core-libs

[openjdk]

@AlanBateman
The core-libs label was successfully removed.

[rkennke]

/label remove graal

[rkennke]

/label remove shenandoah

[rkennke]

/label add hotspot-runtime
/label add hotspot-gc

[openjdk]

@rkennke
The graal label was successfully removed.

[openjdk]

@rkennke
The shenandoah label was successfully removed.

[openjdk]

@rkennke
The hotspot-runtime label was successfully added.

[openjdk]

@rkennke
The hotspot-gc label was successfully added.

[openjdk]

@rkennke
This pull request will not be integrated until the JEP-450 has been targeted.

[rkennke]

It ignores the offset, right? Or are you saying that offset must be 0 on that path?

[magicus]

Build changes look good. I have not looked at any other changes.

/reviewers 3

[openjdk]

@magicus
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 3 (with at least 1 Reviewer, 2 Authors).

[magicus]

@rkennke Note that the Skara bot removed the RFR label when you changed the title to no longer match a JBS issue. This means that no emails will be sent to the corresponding lists. I am not sure if this was intentional on your part.

[rkennke]

@rkennke Note that the Skara bot removed the RFR label when you changed the title to no longer match a JBS issue. This means that no emails will be sent to the corresponding lists. I am not sure if this was intentional on your part.

Thanks for pointing that out! No it was not intentional. Mark changed the title in the JBS issue, and I copied that over, but forgot the actual issue number. Should be fixed now.

[openjdk]

@rkennke this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8305895-v3
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[openjdk]

⚠️ @rkennke This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[rkennke]

Superseding by #20677