On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) >> #20603 and #20605, plus the Tiny Class-Pointers parts that have been >> previously missing. >> >> 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 add some changes to GC forwarding (see >> below) to protect the relevant (upper 22) 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. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now >> uses a bit to indicate 'self-forwarding'. This is needed to preserve the >> crucial Klass* bits in the header. This also allows to get rid of >> preserved-header machinery in SerialGC and G1 (Parallel GC abuses >> preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We >> have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, >> we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the >> GC forwarding at all). >> - 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 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 >> _co... > > Roman Kennke has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of > CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Ah there are some exceptions: x86: `src/hotspot/cpu/x86/vm_version_x86.cpp: AlignVector = !UseUnalignedLoadStores;` if (supports_sse4_2()) { // new ZX cpus if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus } } So I suppose some older platforms may be affected, though I have not seen one yet. They would have to be missing the unaligned `movdqu` instructions. aarch64: `src/hotspot/cpu/aarch64/vm_version_aarch64.cpp: AlignVector = AvoidUnalignedAccesses;` // Ampere eMAG if (_cpu == CPU_AMCC && (_model == CPU_MODEL_EMAG) && (_variant == 0x3)) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX if (_cpu == CPU_CAVIUM && (_model == 0xA1)) { guarantee(_variant != 0, "Pre-release hardware no longer supported."); if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX2 if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) || (_cpu == CPU_BROADCOM && (_model == 0x516))) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // HiSilicon TSV110 if (_cpu == CPU_HISILICON && _model == 0xd01) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } So yes, some platforms are affected. But they seem to be the exception. And again: we have only had `ObjectAlignmentInBytes=8` alignment for vectors since forever - and no platform vendor has ever complained about that. Arrays never had a stronger alignment guarantee than that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483528037 PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483531916
