From cslucas at openjdk.org  Tue Sep 16 21:47:31 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 16 Sep 2025 21:47:31 GMT
Subject: [master] RFR: 8347710: [Lilliput] Implement 4 byte headers [v8]
In-Reply-To: <DWafExMTeycqf2396uBmeiQqEer-mCzCxJkNjv125ZE=.ef1525f8-9469-458b-9276-bb4e7abff49d@github.com>
References: <3F1pXSToMPvaacJejJ-8CXQSORY-x4WIDAeT26g1gqE=.afdadc1c-3e5e-4be6-81e7-bbc31716da04@github.com>
 <DWafExMTeycqf2396uBmeiQqEer-mCzCxJkNjv125ZE=.ef1525f8-9469-458b-9276-bb4e7abff49d@github.com>
Message-ID: <cCWWAFOb7D4RlChPwcNYqY_cJq4Z3RjU024b3NE37gc=.8f119bf6-f722-45aa-a791-f93006053673@github.com>

On Fri, 24 Jan 2025 15:34:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Packs/reduces header bits to just 4 bytes.
>> 
>> This reduces the number of Klass* bits to 19 bits, which allows for ~500,000 classes.
>> 
>> Testing:
>> 
>> - tier1 (-UCOH)
>> - tier2 (-UCOH)
>> - tier1 (+UCOH)
>> - tier2 (+UCOH)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 724:

> 722:     } else {
> 723:       if (UseCompactObjectHeaders) {
> 724:         base_off = 0; /* FIXME */

Should this have been fixed before merge?

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 454:

> 452:   const char* base_desc = nullptr;
> 453:   JVMCIKlassHandle klass(THREAD);
> 454:   if (offset == 1 /*oopDesc::klass_offset_in_bytes()*/) {

@rkennke I'm seeing a crash internally in Graal and I'm suspecting that this line may be the culprit. The error is:


Caused by: java.lang.IllegalArgumentException: Unexpected arguments: Ljdk/vm/ci/hotspot/DirectHotSpotObjectConstantImpl; 8 true
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.getResolvedJavaType0(Native Method)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.getResolvedJavaType(CompilerToVM.java:1020)
...

I'm wondering if the commented part of the condition was supposed to be uncommented at some point.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/193#discussion_r2353719217
PR Review Comment: https://git.openjdk.org/lilliput/pull/193#discussion_r2353726025

From stuefe at openjdk.org  Thu Sep 18 15:03:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Sep 2025 15:03:01 GMT
Subject: [master] RFR: 8347710: [Lilliput] Implement 4 byte headers [v8]
In-Reply-To: <cCWWAFOb7D4RlChPwcNYqY_cJq4Z3RjU024b3NE37gc=.8f119bf6-f722-45aa-a791-f93006053673@github.com>
References: <3F1pXSToMPvaacJejJ-8CXQSORY-x4WIDAeT26g1gqE=.afdadc1c-3e5e-4be6-81e7-bbc31716da04@github.com>
 <DWafExMTeycqf2396uBmeiQqEer-mCzCxJkNjv125ZE=.ef1525f8-9469-458b-9276-bb4e7abff49d@github.com>
 <cCWWAFOb7D4RlChPwcNYqY_cJq4Z3RjU024b3NE37gc=.8f119bf6-f722-45aa-a791-f93006053673@github.com>
Message-ID: <q0EKgwy2QLilVGkNxQlYvHtfYnvxAhw5HxNlaT8zeq0=.98d74650-5cbd-4667-a20b-8cadb178065a@github.com>

On Tue, 16 Sep 2025 21:44:01 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 454:
> 
>> 452:   const char* base_desc = nullptr;
>> 453:   JVMCIKlassHandle klass(THREAD);
>> 454:   if (offset == 1 /*oopDesc::klass_offset_in_bytes()*/) {
> 
> @rkennke I'm seeing a crash internally in Graal and I'm suspecting that this line may be the culprit. The error is:
> 
> 
> Caused by: java.lang.IllegalArgumentException: Unexpected arguments: Ljdk/vm/ci/hotspot/DirectHotSpotObjectConstantImpl; 8 true
> 	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.getResolvedJavaType0(Native Method)
> 	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.getResolvedJavaType(CompilerToVM.java:1020)
> ...
> 
> I'm wondering if the commented part of the condition was supposed to be uncommented at some point.

Did you really intend to use *4-byte* headers in Graal, e.g., as an experiment? This is still a work-in-progress (albeit quite progressed). The official Lilliput was merged into mainline; the lilliput repo now contains the ongoing 4-byte header work.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/193#discussion_r2359750856

From rkennke at openjdk.org  Fri Sep 26 09:43:15 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 09:43:15 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling
Message-ID: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>

We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.

The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.

This change fixes:
- It reverts the default CCSS to 1G
- It sets CCSS to 512M when running with COH
- It makes the auto-sizing work by setting the correct encoding range
- It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')

Testing:
- [x] tier1
- [x] tier2
- [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
- [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
- [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)

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

Commit messages:
 - 8368755: [Lilliput] Fix CompressedClassSpaceSize handling

Changes: https://git.openjdk.org/lilliput/pull/203/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=203&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368755
  Stats: 8 lines in 4 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/lilliput/pull/203.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/203/head:pull/203

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

From stuefe at openjdk.org  Fri Sep 26 10:55:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 Sep 2025 10:55:15 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling
In-Reply-To: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
Message-ID: <fkzH91uSy25nriBcODdHcKIPQuzLhMsP_I6hujJ4ofo=.8bfe63f0-31af-45b9-8dee-6a5f802d0590@github.com>

On Fri, 26 Sep 2025 09:35:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
> 
> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
> 
> This change fixes:
> - It reverts the default CCSS to 1G
> - It sets CCSS to 512M when running with COH
> - It makes the auto-sizing work by setting the correct encoding range
> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
> 
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)

src/hotspot/share/runtime/arguments.cpp line 3772:

> 3770:   }
> 3771:   if (UseCompactObjectHeaders && FLAG_IS_DEFAULT(CompressedClassSpaceSize)) {
> 3772:     FLAG_SET_DEFAULT(CompressedClassSpaceSize, 512 * M);

This may be a bit less ugly and hard-coded:

Suggestion:

    FLAG_SET_DEFAULT(CompressedClassSpaceSize, CompressedKlassPointers::max_klass_range_size_coh);


with this patch in addition:


diff --git a/src/hotspot/share/oops/compressedKlass.cpp b/src/hotspot/share/oops/compressedKlass.cpp
index d7c97d3c8d5..bf45f4ecd78 100644
--- a/src/hotspot/share/oops/compressedKlass.cpp
+++ b/src/hotspot/share/oops/compressedKlass.cpp
@@ -47,6 +47,7 @@ size_t CompressedKlassPointers::_protection_zone_size = 0;
 size_t CompressedKlassPointers::max_klass_range_size() {
 #ifdef _LP64
   const size_t encoding_allows = nth_bit(narrow_klass_pointer_bits() + max_shift());
+  assert(!UseCompactObjectHeaders || max_klass_range_size_coh == encoding_allows, "Sanity");
   constexpr size_t cap = 4 * G;
   return MIN2(encoding_allows, cap);
 #else
diff --git a/src/hotspot/share/oops/compressedKlass.hpp b/src/hotspot/share/oops/compressedKlass.hpp
index 64b9fcf9c82..4f94675d8ed 100644
--- a/src/hotspot/share/oops/compressedKlass.hpp
+++ b/src/hotspot/share/oops/compressedKlass.hpp
@@ -192,6 +192,10 @@ class CompressedKlassPointers : public AllStatic {
   // resulting from the current encoding settings (base, shift), capped to a certain max. value.
   static size_t max_klass_range_size();
 
+  // For use before pre-initialization
+  static constexpr size_t max_klass_range_size_coh =
+      nth_bit(narrow_klass_pointer_bits_coh + max_shift_coh);
+
   // On 64-bit, we need the class space to confine Klass structures to the encoding range, which is determined
   // by bit size of narrowKlass IDs and the shift. On 32-bit, we support compressed class pointer only
   // "pro-forma": narrowKlass have the same size as addresses (32 bits), and therefore the encoding range is

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/203#discussion_r2381975977

From rkennke at openjdk.org  Fri Sep 26 12:28:13 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 12:28:13 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling [v2]
In-Reply-To: <fkzH91uSy25nriBcODdHcKIPQuzLhMsP_I6hujJ4ofo=.8bfe63f0-31af-45b9-8dee-6a5f802d0590@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
 <fkzH91uSy25nriBcODdHcKIPQuzLhMsP_I6hujJ4ofo=.8bfe63f0-31af-45b9-8dee-6a5f802d0590@github.com>
Message-ID: <z1cOBy5XoEDBqPnfebOv21_3UTUDpRyERPwfxmXmXbA=.b9fe3ad3-a9de-42d2-8828-ccfc9fbbc987@github.com>

On Fri, 26 Sep 2025 10:51:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid hard-coding encoding range
>
> src/hotspot/share/runtime/arguments.cpp line 3772:
> 
>> 3770:   }
>> 3771:   if (UseCompactObjectHeaders && FLAG_IS_DEFAULT(CompressedClassSpaceSize)) {
>> 3772:     FLAG_SET_DEFAULT(CompressedClassSpaceSize, 512 * M);
> 
> This may be a bit less ugly and hard-coded:
> 
> Suggestion:
> 
>     FLAG_SET_DEFAULT(CompressedClassSpaceSize, CompressedKlassPointers::max_klass_range_size_coh);
> 
> 
> with this patch in addition:
> 
> 
> diff --git a/src/hotspot/share/oops/compressedKlass.cpp b/src/hotspot/share/oops/compressedKlass.cpp
> index d7c97d3c8d5..bf45f4ecd78 100644
> --- a/src/hotspot/share/oops/compressedKlass.cpp
> +++ b/src/hotspot/share/oops/compressedKlass.cpp
> @@ -47,6 +47,7 @@ size_t CompressedKlassPointers::_protection_zone_size = 0;
>  size_t CompressedKlassPointers::max_klass_range_size() {
>  #ifdef _LP64
>    const size_t encoding_allows = nth_bit(narrow_klass_pointer_bits() + max_shift());
> +  assert(!UseCompactObjectHeaders || max_klass_range_size_coh == encoding_allows, "Sanity");
>    constexpr size_t cap = 4 * G;
>    return MIN2(encoding_allows, cap);
>  #else
> diff --git a/src/hotspot/share/oops/compressedKlass.hpp b/src/hotspot/share/oops/compressedKlass.hpp
> index 64b9fcf9c82..4f94675d8ed 100644
> --- a/src/hotspot/share/oops/compressedKlass.hpp
> +++ b/src/hotspot/share/oops/compressedKlass.hpp
> @@ -192,6 +192,10 @@ class CompressedKlassPointers : public AllStatic {
>    // resulting from the current encoding settings (base, shift), capped to a certain max. value.
>    static size_t max_klass_range_size();
>  
> +  // For use before pre-initialization
> +  static constexpr size_t max_klass_range_size_coh =
> +      nth_bit(narrow_klass_pointer_bits_coh + max_shift_coh);
> +
>    // On 64-bit, we need the class space to confine Klass structures to the encoding range, which is determined
>    // by bit size of narrowKlass IDs and the shift. On 32-bit, we support compressed class pointer only
>    // "pro-forma": narrowKlass have the same size as addresses (32 bits), and therefore the encoding range is

Ok, good idea. It brings in a bunch of stuff from upstream JDK that is not yet present in Lilliput (yes, we're quite a bit behind atm...) but that is ok.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/203#discussion_r2382254800

From rkennke at openjdk.org  Fri Sep 26 12:28:10 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 12:28:10 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling [v2]
In-Reply-To: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
Message-ID: <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>

> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
> 
> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
> 
> This change fixes:
> - It reverts the default CCSS to 1G
> - It sets CCSS to 512M when running with COH
> - It makes the auto-sizing work by setting the correct encoding range
> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
> 
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)

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

  Avoid hard-coding encoding range

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/203/files
  - new: https://git.openjdk.org/lilliput/pull/203/files/66ae0a2e..5cc6d531

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

  Stats: 17 lines in 3 files changed: 10 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/lilliput/pull/203.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/203/head:pull/203

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

From stuefe at openjdk.org  Fri Sep 26 14:56:31 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 Sep 2025 14:56:31 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling [v2]
In-Reply-To: <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
 <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
Message-ID: <6iFq0D9fvqJH4zwnTqFAZwDKQaxrMxgeCgEtbyFQoB0=.1b27820a-3e08-4084-9f3f-73f8e6c7fc80@github.com>

On Fri, 26 Sep 2025 12:28:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
>> 
>> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
>> 
>> This change fixes:
>> - It reverts the default CCSS to 1G
>> - It sets CCSS to 512M when running with COH
>> - It makes the auto-sizing work by setting the correct encoding range
>> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
>> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
>> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid hard-coding encoding range

good

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/203#pullrequestreview-3272636650

From rkennke at openjdk.org  Fri Sep 26 14:56:33 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 14:56:33 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling [v2]
In-Reply-To: <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
 <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
Message-ID: <HcG2wIKiznmvjzMNJv7nDATT94AukLMrgoaxYUUpdpA=.2ef08f0e-f026-4f4c-9074-a0a29ef7291e@github.com>

On Fri, 26 Sep 2025 12:28:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
>> 
>> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
>> 
>> This change fixes:
>> - It reverts the default CCSS to 1G
>> - It sets CCSS to 512M when running with COH
>> - It makes the auto-sizing work by setting the correct encoding range
>> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
>> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
>> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid hard-coding encoding range

GHA failures look like unrelated infra issues.

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

PR Comment: https://git.openjdk.org/lilliput/pull/203#issuecomment-3339048640

From rkennke at openjdk.org  Fri Sep 26 16:26:17 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 16:26:17 GMT
Subject: [master] RFR: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling [v2]
In-Reply-To: <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
 <p0sTq7SmpQlK8-vQs6b6bqH2SWAWW3SBYolrQgRtraY=.82d6c6c2-534c-4aa3-b469-1a365fe9d8c6@github.com>
Message-ID: <pesDNhopja4RknUpYBqCTCOdbzxg5ZrDIBVTTheHmII=.cc26a2f6-1b0c-4dae-932f-3a06a255571b@github.com>

On Fri, 26 Sep 2025 12:28:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
>> 
>> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
>> 
>> This change fixes:
>> - It reverts the default CCSS to 1G
>> - It sets CCSS to 512M when running with COH
>> - It makes the auto-sizing work by setting the correct encoding range
>> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
>> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
>> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid hard-coding encoding range

Thank you!

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

PR Comment: https://git.openjdk.org/lilliput/pull/203#issuecomment-3339467978

From rkennke at openjdk.org  Fri Sep 26 16:29:35 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Sep 2025 16:29:35 GMT
Subject: [master] Integrated: 8368755: [Lilliput] Fix CompressedClassSpaceSize
 handling
In-Reply-To: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
References: <JpJOfs2q9BHjFs1xJNUVimhazyVVVECasmNpJpIIa_g=.79e96c81-d22e-4881-bd46-278af43fa2ad@github.com>
Message-ID: <uZvBXWKErzz7h0_HiHH0wmHKWfc6lAQuFF0MKgI8Jl8=.367ea5a8-2062-45ce-90b6-202986471c40@github.com>

On Fri, 26 Sep 2025 09:35:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently set the default CompressedClassSpaceSize to 128M - much lower than the current upstream default of 1G, and still much lower than the possible encoding range with 4-byte-headers of 512M. I think I did this earlier to make some tests pass and to address a problem with CDS which also wants a smallish share of it, but I have in-fact only hidden a bug.
> 
> The way it should work is to set the CompressedClassSpaceSize to 512M and let CDS take its share and use the rest for class-space. This is infact implemented by [JDK-8332514](https://bugs.openjdk.org/browse/JDK-8332514) since a while. However, there is a bug there that prevents it from working with 4-byte-headers: it has 4G encoding range hard-coded.
> 
> This change fixes:
> - It reverts the default CCSS to 1G
> - It sets CCSS to 512M when running with COH
> - It makes the auto-sizing work by setting the correct encoding range
> - It fixes a test that tries to use CCSS*2. I changed it to use CCSS/2, I think this is still in the spirit of the test ('use a different CCSS and see if it still works')
> 
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] gc/arguments/TestUseCompressedOopsErgoTools.java (affected by the change)
> - [x] runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java (failed before, fixed by this change)
> - [x] runtime/cds/appcds/LotsOfJRTClasses.java (failed before, fixed by this change)

This pull request has now been integrated.

Changeset: 56c3c3b3
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/56c3c3b35fcf376325aaf46218cc186b411afe6f
Stats:     24 lines in 6 files changed: 14 ins; 0 del; 10 mod

8368755: [Lilliput] Fix CompressedClassSpaceSize handling

Reviewed-by: stuefe

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

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