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

rkennke · 2024-08-22T13:35:08Z

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 _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.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires a JEP request to be targeted
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) (Withdrawn)

Reviewers

Magnus Ihse Bursie (@magicus - Reviewer) Review applies to 1b907cc8
Leonid Mesnik (@lmesnik - Reviewer) Review applies to 1ef6394d
Thomas Schatzl (@tschatzl - Reviewer) Review applies to 1b907cc8
Coleen Phillimore (@coleenp - Reviewer)
Stefan Karlsson (@stefank - Reviewer)
Matias Saavedra Silva (@matias9927 - Reviewer) Review applies to 0d8a9236
Roberto Castañeda Lozano (@robcasloz - Reviewer) Review applies to b289ef88
Volodymyr Paprotski (@vpaprotsk - Author) Review applies to e4c08780
Yudi Zheng (@mur47x111 - Committer) Review applies to 1b907cc8
Erik Gahlin (@egahlin - Reviewer) Review applies to 1ef6394d
Thomas Stuefe (@tstuefe - Reviewer)
Paul Hohensee (@phohensee - Reviewer)

Contributors

Sandhya Viswanathan <[email protected]>
Martin Doerr <[email protected]>
Hamlin Li <[email protected]>
Thomas Stuefe <[email protected]>
Amit Kumar <[email protected]>
Stefan Karlsson <[email protected]>
Coleen Phillimore <[email protected]>
Axel Boldt-Christmas <[email protected]>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20677

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2024-08-22T13:35:43Z

👋 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 · 2024-08-22T13:38:12Z

@rkennke This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Co-authored-by: Sandhya Viswanathan <[email protected]>
Co-authored-by: Martin Doerr <[email protected]>
Co-authored-by: Hamlin Li <[email protected]>
Co-authored-by: Thomas Stuefe <[email protected]>
Co-authored-by: Amit Kumar <[email protected]>
Co-authored-by: Stefan Karlsson <[email protected]>
Co-authored-by: Coleen Phillimore <[email protected]>
Co-authored-by: Axel Boldt-Christmas <[email protected]>
Reviewed-by: coleenp, stefank, stuefe, phh, ihse, lmesnik, tschatzl, matsaave, rcastanedalo, vpaprotski, yzheng, egahlin

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 20 new commits pushed to the master branch:

72f67fb: 8343411: Test fail on Windows due to "An established connection was aborted by the software in your host machine"
7d6a2f3: 8342860: Fix more NULL usage backsliding
f6edfe5: 8343506: [s390x] multiple test failures with ubsan
96eed7f: 8343306: javac is failing to determine if a class and a sealed interface are disjoint
0c281ac: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016
2e58ede: 8341399: Add since checker tests to the langtools modules
c7f071c: 8343189: [REDO] JDK-8295269 G1: Improve slow startup due to predictor initialization
a9e53bb: 8343783: Improve asserts in concurrentHashTable.inline.hpp
bf5c3ce: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling
a10b1cc: 8340532: C2: assert(is_OuterStripMinedLoop()) failed: invalid node class: IfTrue
... and 10 more: https://git.openjdk.org/jdk/compare/d3c042f9a0cd91e7cdf7f45cb0ea387f7ba9785b...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2024-08-22T13:39:24Z

@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.

rkennke · 2024-08-22T13:45:39Z

/label remove core-libs
/label add hotspot-gc
/label add hotspot-runtime

rkennke · 2024-08-22T13:46:41Z

/jep JEP-450

openjdk · 2024-08-22T13:46:42Z

@rkennke
The core-libs label was successfully removed.

openjdk · 2024-08-22T13:47:48Z

@rkennke
The hotspot-gc label was successfully added.

openjdk · 2024-08-22T13:48:40Z

@rkennke
The hotspot-runtime label was successfully added.

openjdk · 2024-08-22T13:49:53Z

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

mlbridge · 2024-08-22T14:53:45Z

Webrevs

rkennke · 2024-11-18T14:35:41Z

@rkennke It just will (silently) not vectorize, thus running slower but still correct.

Ok, I think we can live with that for now.

As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away.

The tests need fixing, though.

eme64 · 2024-11-18T14:36:17Z

@merykitty the object base is always at least 8-byte aligned, see ObjectAlignmentInBytes - this also holds for all arrays. But the issue is the offset from the object base to the array payload.

@rkennke yes, working on fixing the tests :)

merykitty · 2024-11-18T14:38:20Z

@eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all.

eme64 · 2024-11-18T14:38:53Z

@rkennke

As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away.

Ah. So we would eventually have not a 12-byte but 8-byte offset from base to payload? Would that happen in all cases? And could that happen before UseCompactObjectHeaders leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of UseCompactObjectHeaders + AlignVector. Though I can surely do it.

eme64 · 2024-11-18T14:41:25Z

@merykitty

Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all.

First: without AlignVector, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though.

merykitty · 2024-11-18T14:43:48Z

@eme64 You will need the alignment for the whole vector (which means 32 bytes for a ymm load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment.

eme64 · 2024-11-18T14:46:09Z

@merykitty I don't think I understand. When and for what do I need the full 32-byte alignment?

eme64 · 2024-11-18T14:48:22Z

@merykitty In AlignmentSolver::solve / src/hotspot/share/opto/vectorization.cpp you can see how I compute if vectors can be aligned.

merykitty · 2024-11-18T14:50:51Z

@eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why vmovdqua requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores.

As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway.

rkennke · 2024-11-18T15:00:51Z

@rkennke

As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away.

Ah. So we would eventually have not a 12-byte but 8-byte offset from base to payload? Would that happen in all cases? And could that happen before UseCompactObjectHeaders leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of UseCompactObjectHeaders + AlignVector. Though I can surely do it.

I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me.

eme64 · 2024-11-18T15:01:09Z

@merykitty I guess we can always use vmovdqu.

And in fact that is exactly what we do:

public class Test {
    static int RANGE = 1024*1024;

    public static void main(String[] args) {
        byte[] aB = new byte[RANGE];
        byte[] bB = new byte[RANGE];
        for (int i = 0; i < 100_000; i++) {
            test1(aB, bB);
        }
    }

    static void test1(byte[] a, byte[] b) {                                    
        for (int i = 0; i < RANGE; i++) {                                                    
            a[i] = b[i];
        }                                                                                     
    }
}

../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java

 ;; B20: #      out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09
  0x00007fc3a4bb0780:   movslq %ebx,%rdi
  0x00007fc3a4bb0783:   movslq %ebx,%r14
  0x00007fc3a4bb0786:   vmovdqu32 0x10(%r13,%r14,1),%zmm1
  0x00007fc3a4bb0791:   vmovdqu32 %zmm1,0x10(%r9,%r14,1)
  0x00007fc3a4bb079c:   vmovdqu32 0x50(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb07a7:   vmovdqu32 %zmm1,0x50(%r9,%rdi,1)
  0x00007fc3a4bb07b2:   vmovdqu32 0x90(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb07bd:   vmovdqu32 %zmm1,0x90(%r9,%rdi,1)
  0x00007fc3a4bb07c8:   vmovdqu32 0xd0(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb07d3:   vmovdqu32 %zmm1,0xd0(%r9,%rdi,1)
  0x00007fc3a4bb07de:   vmovdqu32 0x110(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb07e9:   vmovdqu32 %zmm1,0x110(%r9,%rdi,1)
  0x00007fc3a4bb07f4:   vmovdqu32 0x150(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb07ff:   vmovdqu32 %zmm1,0x150(%r9,%rdi,1)
  0x00007fc3a4bb080a:   vmovdqu32 0x190(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb0815:   vmovdqu32 %zmm1,0x190(%r9,%rdi,1)
  0x00007fc3a4bb0820:   vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1
  0x00007fc3a4bb082b:   vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1)   ;*bastore {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Test::test1@14 (line 14)
  0x00007fc3a4bb0836:   add    $0x200,%ebx                  ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Test::test1@15 (line 13)
  0x00007fc3a4bb083c:   cmp    %r11d,%ebx
  0x00007fc3a4bb083f:   jl     0x00007fc3a4bb0780

merykitty · 2024-11-18T15:20:17Z

@eme64 What I mean here is that AlignVector seems useless because the accesses are going to be misaligned either way.

eme64 · 2024-11-18T16:17:36Z

@merykitty FYI:

src/hotspot/share/opto/vectorization.hpp: static bool vectors_should_be_aligned() { return !Matcher::misaligned_vectors_ok() || AlignVector; }

The relevant code:

src/hotspot/cpu/x86/matcher_x86.hpp:  static constexpr bool misaligned_vectors_ok() {
  // x86 supports misaligned vectors store/load.
  static constexpr bool misaligned_vectors_ok() {
    return true;
  }


src/hotspot/cpu/ppc/matcher_ppc.hpp:  static constexpr bool misaligned_vectors_ok() {
  // PPC implementation uses VSX load/store instructions (if
  // SuperwordUseVSX) which support 4 byte but not arbitrary alignment
  static constexpr bool misaligned_vectors_ok() {
    return false;
  }

src/hotspot/cpu/aarch64/matcher_aarch64.hpp:  static constexpr bool misaligned_vectors_ok() {
  // aarch64 supports misaligned vectors store/load.
  static constexpr bool misaligned_vectors_ok() {
    return true;
  }

src/hotspot/cpu/s390/matcher_s390.hpp:  static constexpr bool misaligned_vectors_ok() {
  // z/Architecture does support misaligned store/load at minimal extra cost.
  static constexpr bool misaligned_vectors_ok() {
    return true;
  }

src/hotspot/cpu/arm/matcher_arm.hpp:  static constexpr bool misaligned_vectors_ok() {
  // ARM doesn't support misaligned vectors store/load.
  static constexpr bool misaligned_vectors_ok() {
    return false;
  }

src/hotspot/cpu/riscv/matcher_riscv.hpp:  static constexpr bool misaligned_vectors_ok() {
  // riscv supports misaligned vectors store/load.
  static constexpr bool misaligned_vectors_ok() {
    return true;
  }

We can see that only PPC and ARM32 have such strict alignment requirements. And it turns out that PPC only needs 4-byte alignment, and ARM32 is fine with 8-byte alignment. So all of our platforms do not necessarily need full vector-width alignment.

eme64 · 2024-11-18T16:26:51Z

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.

eme64 · 2024-11-18T16:28:33Z

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.

eme64 · 2024-11-18T16:49:00Z

@rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis):
JDK-8344424: C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector

rkennke · 2024-11-18T17:05:52Z

@rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis): JDK-8344424: C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector

Thanks!

theRealAph · 2024-11-19T09:41:58Z

So yes, some platforms [have alignment requirements for vectors]. But they seem to be the exception.

All AArch64 implementations work with unaligned vectors – that's in the architecture spec – but some designs thaht were made years ago performed badly. It's not a problem with new designs.

…xperimental) Fixes: 44ec501 ("8305895: Implement JEP 450: Compact Object Headers (Experimental)") Fixes: ff12ff5 ("8340453: C2: Improve encoding of LoadNKlass for compact headers") Follow-up: 44ec501 ("8305895: Implement JEP 450: Compact Object Headers (Experimental)") Follow-up: ff12ff5 ("8340453: C2: Improve encoding of LoadNKlass for compact headers") Link: openjdk#20677 Link: openjdk#22203 Signed-off-by: Bingwu Zhang <[email protected]>

…rimental) Fixes: 44ec501 ("8305895: Implement JEP 450: Compact Object Headers (Experimental)") Fixes: ff12ff5 ("8340453: C2: Improve encoding of LoadNKlass for compact headers") Follow-up: 44ec501 ("8305895: Implement JEP 450: Compact Object Headers (Experimental)") Follow-up: ff12ff5 ("8340453: C2: Improve encoding of LoadNKlass for compact headers") Link: openjdk#20677 Link: openjdk#22203 Signed-off-by: Bingwu Zhang <[email protected]>

openjdk bot added the csr Pull request needs approved CSR before integration label Aug 22, 2024

openjdk bot added graal [email protected] serviceability [email protected] build [email protected] hotspot [email protected] core-libs [email protected] shenandoah [email protected] labels Aug 22, 2024

rkennke force-pushed the JDK-8305895-v4 branch from 96ec3c2 to ad7e13b Compare August 22, 2024 13:40

openjdk bot removed the core-libs [email protected] label Aug 22, 2024

openjdk bot added the hotspot-gc [email protected] label Aug 22, 2024

openjdk bot added the hotspot-runtime [email protected] label Aug 22, 2024

openjdk bot added the jep label Aug 22, 2024

rkennke force-pushed the JDK-8305895-v4 branch from ad7e13b to dfe36bd Compare August 22, 2024 13:51

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

ed03217

rkennke force-pushed the JDK-8305895-v4 branch from dfe36bd to ed03217 Compare August 22, 2024 14:47

rkennke marked this pull request as ready for review August 22, 2024 14:47

This was referenced Aug 22, 2024

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

Closed

8305898: Alternative self-forwarding mechanism #20603

Closed

8305896: Alternative full GC forwarding #20605

Closed

openjdk bot added the rfr Pull request is ready for review label Aug 22, 2024

graalvmbot mentioned this pull request Nov 19, 2024

[GR-59836] Update labsjdk to 24+24-jvmci-b01 oracle/graal#10108

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

rkennke commented Aug 22, 2024 •

edited by openjdk bot

Loading

bridgekeeper bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024 •

edited

Loading

openjdk bot commented Aug 22, 2024

rkennke commented Aug 22, 2024

rkennke commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

mlbridge bot commented Aug 22, 2024 •

edited

Loading

rkennke commented Nov 18, 2024 •

edited

Loading

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024 •

edited

Loading

rkennke commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

rkennke commented Nov 18, 2024

theRealAph commented Nov 19, 2024

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

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

Conversation

rkennke commented Aug 22, 2024 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Contributors

Reviewing

bridgekeeper bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024 • edited Loading

openjdk bot commented Aug 22, 2024

rkennke commented Aug 22, 2024

rkennke commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

openjdk bot commented Aug 22, 2024

mlbridge bot commented Aug 22, 2024 • edited Loading

Webrevs

rkennke commented Nov 18, 2024 • edited Loading

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024 • edited Loading

rkennke commented Nov 18, 2024

eme64 commented Nov 18, 2024

merykitty commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

eme64 commented Nov 18, 2024

rkennke commented Nov 18, 2024

theRealAph commented Nov 19, 2024

rkennke commented Aug 22, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Aug 22, 2024 •

edited

Loading

mlbridge bot commented Aug 22, 2024 •

edited

Loading

rkennke commented Nov 18, 2024 •

edited

Loading

merykitty commented Nov 18, 2024 •

edited

Loading