From rkennke at openjdk.org  Thu Dec  5 15:54:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 5 Dec 2024 15:54:15 GMT
Subject: [master] RFR: Merge jdk:jdk-24+9
Message-ID: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>

Merges upstream tag merge-jdk-24+9 such that the repo is identical to that tag afterwards. I.e. we discard all changes from the lilliput repo, because JEP-450 has been upstreamed and that subsumes all work that we have maintained here.

The plan is to shift this repo to development work on Lilliput-2 ('4-byte-headers').

Ok?

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

Commit messages:
 - Merge branch 'master' into merge-jdk-24+9
 - 8337027: Parallel: Obsolete BaseFootPrintEstimate
 - 8324345: Stack overflow during C2 compilation when splitting memory phi
 - 8331090: Run Ideal_minmax before de-canonicalizing CMoves
 - 8337421: RISC-V: client VM build failure after JDK-8335191
 - 8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code
 - 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code
 - 8336635: Add IR test for Reference.refersTo intrinsic
 - 8336242: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (again)
 - 8336912: G1: Undefined behavior for G1ConfidencePercent=0
 - ... and 460 more: https://git.openjdk.org/lilliput/compare/fdfcf46a...a90def59

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/lilliput/pull/189/files
  Stats: 62476 lines in 1790 files changed: 33010 ins; 21022 del; 8444 mod
  Patch: https://git.openjdk.org/lilliput/pull/189.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/189/head:pull/189

PR: https://git.openjdk.org/lilliput/pull/189

From stuefe at openjdk.org  Thu Dec  5 16:18:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 16:18:12 GMT
Subject: [master] RFR: Merge jdk:jdk-24+9
In-Reply-To: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
References: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
Message-ID: <qAnZRqNomJrK0V6QZYidxFxaIcL10R7-CAdzPYR4XuU=.37a8959a-89d9-487b-a047-5759c1fa100a@github.com>

On Thu, 5 Dec 2024 15:48:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Merges upstream tag merge-jdk-24+9 such that the repo is identical to that tag afterwards. I.e. we discard all changes from the lilliput repo, because JEP-450 has been upstreamed and that subsumes all work that we have maintained here.
> 
> The plan is to shift this repo to development work on Lilliput-2 ('4-byte-headers').
> 
> Ok?

ok!

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

Marked as reviewed by stuefe (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/189#pullrequestreview-2482207866

From rkennke at openjdk.org  Thu Dec  5 16:59:45 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 5 Dec 2024 16:59:45 GMT
Subject: [master] RFR: Merge jdk:jdk-24+9 [v2]
In-Reply-To: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
References: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
Message-ID: <RrfclqM_CSRkjbbMKx_JdMI5M4lSiZnn2CeFpKHgaN0=.9f6d505f-33d1-4c51-b384-847cf0d06fd7@github.com>

> Merges upstream tag merge-jdk-24+9 such that the repo is identical to that tag afterwards. I.e. we discard all changes from the lilliput repo, because JEP-450 has been upstreamed and that subsumes all work that we have maintained here.
> 
> The plan is to shift this repo to development work on Lilliput-2 ('4-byte-headers').
> 
> Ok?

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 193 commits:

 - Merge branch 'master' into merge-jdk-24+9
 - Add some inlining and avoid CAS for quick_enter for lightweight locking.
   
   Reviewed-by: aboldtch
 - Tiny Class-Pointers
 - 8305895: Implementation: JEP 450: Compact Object Headers (Experimental)
 - 8305896: Alternative full GC forwarding
 - 8305898: Alternative self-forwarding mechanism
 - 8315884: New Object to ObjectMonitor mapping
 - Lilliput conf changes for jcheck
 - Merge branch 'lilliput_v6' into lilliput_rebase_target
 - Tiny Class-Pointers
 - ... and 183 more: https://git.openjdk.org/lilliput/compare/e4c7850c...a90def59

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

Changes: https://git.openjdk.org/lilliput/pull/189/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=189&range=01
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/189.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/189/head:pull/189

PR: https://git.openjdk.org/lilliput/pull/189

From rkennke at openjdk.org  Thu Dec  5 16:59:46 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 5 Dec 2024 16:59:46 GMT
Subject: [master] RFR: Merge jdk:jdk-24+9
In-Reply-To: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
References: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
Message-ID: <JSojC8tUPrUvYWQ_FPwFEj_K1m9mo8mOZK0Xj9QwaMQ=.2fa9a3e6-b98c-4135-ad7e-3178b00b08c0@github.com>

On Thu, 5 Dec 2024 15:48:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Merges upstream tag merge-jdk-24+9 such that the repo is identical to that tag afterwards. I.e. we discard all changes from the lilliput repo, because JEP-450 has been upstreamed and that subsumes all work that we have maintained here.
> 
> The plan is to shift this repo to development work on Lilliput-2 ('4-byte-headers').
> 
> Ok?

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput/pull/189#issuecomment-2520913749

From rkennke at openjdk.org  Thu Dec  5 16:59:48 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 5 Dec 2024 16:59:48 GMT
Subject: [master] Integrated: Merge jdk:jdk-24+9
In-Reply-To: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
References: <Oeg46BHF24e7XZkKuvoGfxbZOGc2hKQfxEy3OkRFqmM=.755d9168-fa40-4b5d-92d2-f1e334a6645b@github.com>
Message-ID: <o6N_kIdDDBEikcNboEgPenlaFBJJ4PA8yOSl-ytPs4M=.de4df3d2-41af-41eb-8486-1e581b02b0d8@github.com>

On Thu, 5 Dec 2024 15:48:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Merges upstream tag merge-jdk-24+9 such that the repo is identical to that tag afterwards. I.e. we discard all changes from the lilliput repo, because JEP-450 has been upstreamed and that subsumes all work that we have maintained here.
> 
> The plan is to shift this repo to development work on Lilliput-2 ('4-byte-headers').
> 
> Ok?

This pull request has now been integrated.

Changeset: 2658a2f6
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/2658a2f6a5d3de5645828381d22cbc97169cdc37
Stats:     62476 lines in 1790 files changed: 33010 ins; 21022 del; 8444 mod

Merge

Reviewed-by: stuefe

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

PR: https://git.openjdk.org/lilliput/pull/189

From rkennke at openjdk.org  Mon Dec  9 10:29:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 9 Dec 2024 10:29:19 GMT
Subject: [master] RFR: Merge jdk:jdk-25+1
Message-ID: <F_PkeDxuz3qYCz4Edga2n9aR6sGXTYnrT7KDT2xlKpg=.edfefd29-e7c2-45b6-bbee-3d44f5441028@github.com>

Merge upstream tag jdk-25+1, results in clean slate upstream state.

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

Commit messages:
 - Merge branch 'master' into merge-jdk-27+1
 - 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread
 - 8344665: Refactor PartialArrayState allocation for reuse
 - 8342979: Start of release updates for JDK 25
 - 8344607: Link Time Optimization - basic support for clang
 - 8345302: Building microbenchmarks require larger Java heap
 - 8345514: Should use internal class name when calling ClassLoader.getResourceAsByteArray
 - 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails ceil_log2 not declared
 - 8328944: NMT reports "unknown" memory
 - 8345565: Remove remaining SecurityManager motivated APIs from sun.reflect.util
 - ... and 1852 more: https://git.openjdk.org/lilliput/compare/2658a2f6...fa8f3f57

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/lilliput/pull/190/files
  Stats: 848328 lines in 9602 files changed: 544702 ins; 239368 del; 64258 mod
  Patch: https://git.openjdk.org/lilliput/pull/190.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/190/head:pull/190

PR: https://git.openjdk.org/lilliput/pull/190

From rkennke at openjdk.org  Tue Dec 10 13:10:49 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Dec 2024 13:10:49 GMT
Subject: [master] RFR: Merge jdk:jdk-25+1 [v2]
In-Reply-To: <F_PkeDxuz3qYCz4Edga2n9aR6sGXTYnrT7KDT2xlKpg=.edfefd29-e7c2-45b6-bbee-3d44f5441028@github.com>
References: <F_PkeDxuz3qYCz4Edga2n9aR6sGXTYnrT7KDT2xlKpg=.edfefd29-e7c2-45b6-bbee-3d44f5441028@github.com>
Message-ID: <FzTFgfgHVygaK-2AczfaSE7MdkreQ67vrFfnWDn64P0=.36225ec8-45c6-46f9-abfc-f21ad8d86e68@github.com>

> Merge upstream tag jdk-25+1, results in clean slate upstream state.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 194 commits:

 - Merge branch 'master' into merge-jdk-27+1
 - Merge
   
   Reviewed-by: stuefe
 - Add some inlining and avoid CAS for quick_enter for lightweight locking.
   
   Reviewed-by: aboldtch
 - Tiny Class-Pointers
 - 8305895: Implementation: JEP 450: Compact Object Headers (Experimental)
 - 8305896: Alternative full GC forwarding
 - 8305898: Alternative self-forwarding mechanism
 - 8315884: New Object to ObjectMonitor mapping
 - Lilliput conf changes for jcheck
 - Merge branch 'lilliput_v6' into lilliput_rebase_target
 - ... and 184 more: https://git.openjdk.org/lilliput/compare/bedb68ab...fa8f3f57

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

Changes: https://git.openjdk.org/lilliput/pull/190/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=190&range=01
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/190.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/190/head:pull/190

PR: https://git.openjdk.org/lilliput/pull/190

From rkennke at openjdk.org  Tue Dec 10 13:10:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Dec 2024 13:10:54 GMT
Subject: [master] Integrated: Merge jdk:jdk-25+1
In-Reply-To: <F_PkeDxuz3qYCz4Edga2n9aR6sGXTYnrT7KDT2xlKpg=.edfefd29-e7c2-45b6-bbee-3d44f5441028@github.com>
References: <F_PkeDxuz3qYCz4Edga2n9aR6sGXTYnrT7KDT2xlKpg=.edfefd29-e7c2-45b6-bbee-3d44f5441028@github.com>
Message-ID: <iPZuzZBT3Gc9VKsJbjSUykpGqwkqVAUvTRSO0Hqr-IM=.247c3349-4786-40db-a30f-8d1380f4d924@github.com>

On Mon, 9 Dec 2024 10:24:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Merge upstream tag jdk-25+1, results in clean slate upstream state.

This pull request has now been integrated.

Changeset: 26b675f6
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/26b675f61a197f89583355cfad7429dd50c54004
Stats:     848328 lines in 9602 files changed: 544702 ins; 239368 del; 64258 mod

Merge

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

PR: https://git.openjdk.org/lilliput/pull/190

From rkennke at openjdk.org  Wed Dec 11 15:51:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 11 Dec 2024 15:51:40 GMT
Subject: [master] RFR: 8346011: [Lilliput] Compact Full-GC Forwarding
Message-ID: <ktCIU61Tr_NUTHBIhPfnuDoQ7nsQPjj9_QoL1D3k-Qg=.bdcc66c2-2452-4f95-b4d5-03b065c6c237@github.com>

The current forwarding scheme that is used during full-GC overrides much of the mark-word. This is a problem for current compact headers when the heap is larger than 8TB (in which case we currently disable compact headers altogether) and becomes a much worse issue with 4-byte-compact-headers, because it would override the compressed class-pointer in the upper header bits.

This implementation uses a side-table (currently 1/512th of the heap size) to store part of the target addresses, and 9 bits in the header for the rest of it. For the full description of the algorithm, see top of fullGCForwarding.hpp.

Testing:
 - [x] hotspot_gc
 - [ ] tier1
 - [ ] tier1 +UseSerialGC
 - [ ] tier1 +UseParallelGC
 - [ ] tier1 +UseShenandoahGC

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

Commit messages:
 - 8346011: [Lilliput] Compact Full-GC Forwarding

Changes: https://git.openjdk.org/lilliput/pull/191/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=191&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346011
  Stats: 546 lines in 13 files changed: 467 ins; 31 del; 48 mod
  Patch: https://git.openjdk.org/lilliput/pull/191.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/191/head:pull/191

PR: https://git.openjdk.org/lilliput/pull/191

From rkennke at openjdk.org  Thu Dec 12 14:55:23 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 12 Dec 2024 14:55:23 GMT
Subject: [master] RFR: 8346011: [Lilliput] Compact Full-GC Forwarding [v2]
In-Reply-To: <ktCIU61Tr_NUTHBIhPfnuDoQ7nsQPjj9_QoL1D3k-Qg=.bdcc66c2-2452-4f95-b4d5-03b065c6c237@github.com>
References: <ktCIU61Tr_NUTHBIhPfnuDoQ7nsQPjj9_QoL1D3k-Qg=.bdcc66c2-2452-4f95-b4d5-03b065c6c237@github.com>
Message-ID: <ewcehfn1YsI8OW5GN1q9moqxV4J0POUZlBt_vMqlXfk=.1175e103-7c24-4b66-a25e-26445bd200b7@github.com>

> The current forwarding scheme that is used during full-GC overrides much of the mark-word. This is a problem for current compact headers when the heap is larger than 8TB (in which case we currently disable compact headers altogether) and becomes a much worse issue with 4-byte-compact-headers, because it would override the compressed class-pointer in the upper header bits.
> 
> This implementation uses a side-table (currently 1/512th of the heap size) to store part of the target addresses, and 9 bits in the header for the rest of it. For the full description of the algorithm, see top of fullGCForwarding.hpp.
> 
> Testing:
>  - [x] hotspot_gc
>  - [ ] tier1
>  - [ ] tier1 +UseSerialGC
>  - [ ] tier1 +UseParallelGC
>  - [ ] tier1 +UseShenandoahGC

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix preservedMarks gtest

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/191/files
  - new: https://git.openjdk.org/lilliput/pull/191/files/eb5ff170..42ca1c80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput&pr=191&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=191&range=00-01

  Stats: 6 lines in 2 files changed: 4 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/191.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/191/head:pull/191

PR: https://git.openjdk.org/lilliput/pull/191

From forax at univ-mlv.fr  Tue Dec 17 17:31:48 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 17 Dec 2024 18:31:48 +0100 (CET)
Subject: Compact header and computed hashCode
Message-ID: <1503822203.27588478.1734456708532.JavaMail.zimbra@univ-eiffel.fr>

Hello,
i was taking a look to the code submitted by Roman to avoid allocating hashCode if not necessary, pretending i'm able to read VM code, when an idea pop up.

I wonder if for small objects (64bits or less) containing only primitives, it's not better to not reserve a space for the hashcode at all and recompute it using the value of the fields ?

R?mi




From rkennke at amazon.de  Tue Dec 17 18:46:20 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Tue, 17 Dec 2024 18:46:20 +0000
Subject: Compact header and computed hashCode
In-Reply-To: <1503822203.27588478.1734456708532.JavaMail.zimbra@univ-eiffel.fr>
References: <1503822203.27588478.1734456708532.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <BC6EB870-1064-4690-8413-0F6362FDE8A0@amazon.de>

Hi Remi,

> i was taking a look to the code submitted by Roman to avoid allocating hashCode if not necessary, pretending i'm able to read VM code, when an idea pop up.
> 
> I wonder if for small objects (64bits or less) containing only primitives, it's not better to not reserve a space for the hashcode at all and recompute it using the value of the fields ?

I guess we could. It would not be strictly an ?identity? hash-code, right - but still valid with respect to the contract hash(x) != hash(y) => x != y. I am not sure how useful that would be. The case where we need to allocate extra space is not so very frequent, and stuff like j.l.Integer or j.l.Long already override their hashCode() method, so would in most cases not be affected by this.

The other problem is that we have an intrinsic in C2 that handles the hash-code 	(see the changes in libraryCall.cpp). This code would also have to deal with that special case, and I am not sure if adding another branch there might not make all other (more common) cases slower.

I need to think this through?

Thanks,
Roman




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597