From bylokhov at amazon.com Thu Oct 2 03:05:54 2025 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Wed, 1 Oct 2025 20:05:54 -0700 Subject: bye stable values, enter lazy constants In-Reply-To: <2a7191e7-097b-4696-a37e-70c63092464b@oracle.com> References: <0c1214f6-c4e5-44c1-b04b-330e38ff41a2@amazon.com> <015c85a4-d117-4b32-9e56-9fb458d7d16f@oracle.com> <033cfbd1-d6c8-4bf4-9f54-c9b7e85c5b89@oracle.com> <39b68d9b-7eeb-4c12-aac3-dd85d5f6a01f@amazon.com>

<2a7191e7-097b-4696-a37e-70c63092464b@oracle.com> Message-ID: <6765d990-d07a-43da-a118-c626ad9d4f4e@amazon.com> On 9/30/25 02:27, Maurizio Cimadamore wrote: > In the new API, LazyConstant.of() is no longer present (unlike > StableValue::of), so I don't think this is an issue (e.g. you _have_ to > pass a lambda). +1 > ``` > class Foo { > ??? private static final LazyConstant LOGGER = > LazyConstant.of(() -> makeLogger(Foo.class)); > > ??? static Logger getLogger() { > ??????? return LOGGER.get(); > ??? } > } > ``` > > The "problem" here is that you have a LOGGER field, and the > implementation of Foo can access that field directly, w/o calling > `getLogger`. Fine. But what can you do with LOGGER if not calling its > get() method (which is also what the getter does) ? I'd like to > understand the concern better here. Even if the LazyConstant field is marked as private, it is still accessible from within the scope of the class. That means it can be read and therefore initialized by other methods in the same class, or even externally via JNI/reflection/etc. This can trigger the evaluation of the lambda expression passed to the lazy factory, causing the value to be computed and stored, even if the intended public factory method was never called. This is a problem if initialization order matters. For example, say Foo.getInstance() is supposed to initialize(and skip) LOGGER/LOGGER1/LOGGER2/etc in a specific order. If the class has multiple loggers (for terminal, filesystem, network, etc.), how can we prevent accidental access to the wrong logger? How do we make sure direct access does not allow premature or out-of-order initialization? I am not saying this feature is absolutely necessary, but it is something we do get to some extent with the holder pattern. >> ?- Handling exceptions more robustly than the Holder idiom > > If an exception is thrown while computing the value is never set on the > lazy constant -- meaning the next call to `get` will re-generate the > same exception. With holder idiom one of the issue is that exceptions > are thrown during initialization of the holder class, which can > sometimes add confusion. It is the main improvement over the holder, and I really like it! This is one of the reason the holder cannot be used in many places in the JDK. -- Best regards, Sergey. From kvn at openjdk.org Thu Oct 2 05:30:02 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 05:30:02 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v2] In-Reply-To: References: Message-ID: > Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L341) > > To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. > > I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/cardTable.cpp#L46) and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. > > @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. > > Changes were testing tier1-5. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Removed card_shift from AOT constants table. Fixed minimal VM build. ------------- Changes: - all: https://git.openjdk.org/leyden/pull/102/files - new: https://git.openjdk.org/leyden/pull/102/files/a1721c98..e94fb605 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=102&range=01 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=102&range=00-01 Stats: 244 lines in 16 files changed: 37 ins; 175 del; 32 mod Patch: https://git.openjdk.org/leyden/pull/102.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/102/head:pull/102 PR: https://git.openjdk.org/leyden/pull/102 From kvn at openjdk.org Thu Oct 2 05:30:03 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 05:30:03 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 23:55:51 GMT, Vladimir Kozlov wrote: > Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L341) > > To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. > > I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/cardTable.cpp#L46) and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. > > @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. > > Changes were testing tier1-5. I updated changes. ------------- PR Comment: https://git.openjdk.org/leyden/pull/102#issuecomment-3359165920 From maurizio.cimadamore at oracle.com Thu Oct 2 08:17:53 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Oct 2025 09:17:53 +0100 Subject: bye stable values, enter lazy constants In-Reply-To: <6765d990-d07a-43da-a118-c626ad9d4f4e@amazon.com> References: <0c1214f6-c4e5-44c1-b04b-330e38ff41a2@amazon.com> <015c85a4-d117-4b32-9e56-9fb458d7d16f@oracle.com> <033cfbd1-d6c8-4bf4-9f54-c9b7e85c5b89@oracle.com> <39b68d9b-7eeb-4c12-aac3-dd85d5f6a01f@amazon.com>

<2a7191e7-097b-4696-a37e-70c63092464b@oracle.com> <6765d990-d07a-43da-a118-c626ad9d4f4e@amazon.com> Message-ID: On 02/10/2025 04:05, Sergey Bylokhov wrote: > On 9/30/25 02:27, Maurizio Cimadamore wrote: >> In the new API, LazyConstant.of() is no longer present (unlike >> StableValue::of), so I don't think this is an issue (e.g. you _have_ to >> pass a lambda). > > +1 > >> ``` >> class Foo { >> ???? private static final LazyConstant LOGGER = >> LazyConstant.of(() -> makeLogger(Foo.class)); >> >> ???? static Logger getLogger() { >> ???????? return LOGGER.get(); >> ???? } >> } >> ``` >> >> The "problem" here is that you have a LOGGER field, and the >> implementation of Foo can access that field directly, w/o calling >> `getLogger`. Fine. But what can you do with LOGGER if not calling its >> get() method (which is also what the getter does) ? I'd like to >> understand the concern better here. > > Even if the LazyConstant field is marked as private, it is still > accessible from within the scope of the class. That means it can be > read and therefore initialized by other methods in the same class, or > even externally via JNI/reflection/etc. This can trigger the > evaluation of the lambda expression passed to the lazy factory, > causing the value to be computed and stored, even if the intended > public factory method was never called. > > This is a problem if initialization order matters. For example, say > Foo.getInstance() is supposed to initialize(and skip) > LOGGER/LOGGER1/LOGGER2/etc in a specific order. If the class has > multiple loggers (for terminal, filesystem, network, etc.), how can we > prevent accidental access to the wrong logger? How do we make sure > direct access does not allow premature or out-of-order initialization? > > I am not saying this feature is absolutely necessary, but it is > something we do get to some extent with the holder pattern. Yep. Thinking more about this, if we ever did the idea you suggested the other day (e.g. declaring static fields inside a method), then you could have tighter scoping e.g. ``` Logger getLogger() { ??? static LazyConstant LOGGER = LazyConstant.of(...); ??? return LOGGER.get(); } ``` (Now, while I think it's useful to have static _classes_ inside a method, I think having a static field in there might be a bit confusing, as it looks like a local variable, but isn't really -- it's a field. So whether that's a good idea or not will have to be assessed separately) My main point here is that there are (as you have noticed) possible general ways to ameliorate the situation which, if provided, LazyConstant could benefit from immediately. > >>> ?- Handling exceptions more robustly than the Holder idiom >> >> If an exception is thrown while computing the value is never set on the >> lazy constant -- meaning the next call to `get` will re-generate the >> same exception. With holder idiom one of the issue is that exceptions >> are thrown during initialization of the holder class, which can >> sometimes add confusion. > > It is the main improvement over the holder, and I really like it! > This is one of the reason the holder cannot be used in many places in > the JDK. Cool - thanks for the feedback. Getting semantics of exceptions correct with a lazy API is always a bit tricky... Maurizio From adinn at openjdk.org Thu Oct 2 08:53:25 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 08:53:25 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 05:30:02 GMT, Vladimir Kozlov wrote: >> Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L341) >> >> To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. >> >> I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/cardTable.cpp#L46) and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. >> >> @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. >> >> Changes were testing tier1-5. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Removed card_shift from AOT constants table. Fixed minimal VM build. Looks ok, modulo a couple of optional suggested tweaks and a name correction for the arm failure. I'm not sure why we are seeing a Shenandoah timeout but it ought to be unrelated as Shenandoah barriers are 1) independent of the (G1) region grain size and 2) access the card table base via a thread local. src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 48: > 46: if (UseCondCardMark) { > 47: Label L_already_dirty; > 48: __ ldrb(rscratch2, Address(obj, rscratch)); Do we need an extra precondition? `precond(!UseCondCardMark || rscratch != rscratch2)` src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 68: > 66: > 67: #ifdef CARDTABLEBARRIERSET_POST_BARRIER_HELPER > 68: assert(!aotCodeCache::is_on(), "this path is not implemented"); Suggestion: assert(!AOTCodeCache::is_on(), "this path is not implemented"); src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 88: > 86: __ move(byte_map_base_adr, byte_map_base_reg); > 87: LIR_Address* byte_map_base_indirect = new LIR_Address(byte_map_base_reg, 0, T_LONG); > 88: //LIR_Opr byte_map_base = gen->new_pointer_register(); Do we need this comment? ------------- Marked as reviewed by adinn (Committer). PR Review: https://git.openjdk.org/leyden/pull/102#pullrequestreview-3293207725 PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2397670560 PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2397781476 PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2397735318 From aph-open at littlepinkcloud.com Thu Oct 2 09:50:16 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 2 Oct 2025 10:50:16 +0100 Subject: bye stable values, enter lazy constants In-Reply-To: References: <0c1214f6-c4e5-44c1-b04b-330e38ff41a2@amazon.com> <015c85a4-d117-4b32-9e56-9fb458d7d16f@oracle.com> <033cfbd1-d6c8-4bf4-9f54-c9b7e85c5b89@oracle.com> <39b68d9b-7eeb-4c12-aac3-dd85d5f6a01f@amazon.com>

<2a7191e7-097b-4696-a37e-70c63092464b@oracle.com> <6765d990-d07a-43da-a118-c626ad9d4f4e@amazon.com> Message-ID: <841f6f2e-5f22-44b7-8aeb-df743ce074fc@littlepinkcloud.com> On 02/10/2025 09:17, Maurizio Cimadamore wrote: > (Now, while I think it's useful to have static_classes_ inside a > method, I think having a static field in there might be a bit confusing, > as it looks like a local variable, but isn't really -- it's a field. So > whether that's a good idea or not will have to be assessed separately) static has worked that way in block scope in C++ for decades, and I don't think it causes any particular problems. Providing something like this would encourage people to use lazy constants in an idiomatic way rather than initializing everything up front. > If an exception is thrown while computing the value is never set on the > lazy constant -- meaning the next call to `get` will re-generate the same exception. This is what happens with block-scope static variables in C++. It does mean that the compiler inserts a hidden mutex whenever such variables are initialized, so implementation requires some thought. -- Andrew Haley (he/him) Java Platform Lead Engineer https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sebastien.deleuze at broadcom.com Thu Oct 2 09:52:05 2025 From: sebastien.deleuze at broadcom.com (Sebastien Deleuze) Date: Thu, 2 Oct 2025 11:52:05 +0200 Subject: Updated benchmark numbers in premain README In-Reply-To: References: Message-ID: For the Spring Petclinic demo, I am not sure yet about the reason for it to be an outlier, but I would suggest to: - Update to a more recent commit than the outdated one (see https://github.com/openjdk/leyden/blob/premain/test/hotspot/jtreg/premain/spring-petclinic/Makefile#L126 ) - Leverage the CDS/AOT cache friendly unpacking feature (available as of Spring Boot 3.3) https://docs.spring.io/spring-boot/reference/packaging/efficient.html - Use a more production-like arrangement by avoiding creating the database schema at startup Spring-boot Getting Started Demo should be also updated to a more recent version and use the CDS/AOT cache friendly unpacking feature. I suggest we collaborate on that. On Tue, Sep 30, 2025 at 9:49?PM wrote: > I've updated the benchmark numbers using the latest premain tip (as of > 2025/09/30): > > > https://github.com/openjdk/leyden/blob/premain/README.md#premain-aot-cache-summary > > There's quite a bit of improvement due to the new compiler tuning changes > by Aleksey. I also added a "2 cores only" mode to emulate microservices > that are allocated very few CPUs. > > > Here are the results of {premain AOT} vs {JDK 25, no CDS, no AOT}. Note > that premain is generally much more beneficial with the 2 Cores Only case, > except for PetClinic: > > > Benchmark Desktop/Server Class (28 Cores) 2 Cores Only > > *---------------------------------------------------------------------------- > *Helidon Quick Start 3.59x 4.11x ++ > JavacBenchApp 50 source files 2.21x 3.17x ++++ > Micronaut First App Demo 2.91x 4.90x +++++++ > Quarkus Getting Started Demo 2.97x 3.74x +++ > Spring-boot Getting Started Demo 4.13x 4.70x ++ > Spring PetClinic Demo 3.33x 3.03x -- ??? > > > > Changes from last time ( > https://github.com/openjdk/leyden/blob/46e03d000efd1b2784ad4dcd4c83310ace498ec0/README.md > ) > > The 2 Core Only case see a lot of improvements with the compiler tuning. > PetClinic is again an outlier. > > Benchmark Desktop/Server Class (28 Cores) 2 Cores Only > > ---------------------------------------------------------------------------- > Helidon Quick Start 3.60 -> 3.59x ~ 3.53 -> 4.11x ++ > JavacBenchApp 50 source files 2.17 -> 2.21x ~ 2.74 -> 3.17x ++ > Micronaut First App Demo 2.85 -> 2.91x + 4.39 -> 4.90x ++ > Quarkus Getting Started Demo 2.73 -> 2.97x ++ 2.95 -> 3.74x +++ > Spring-boot Getting Started Demo 3.96 -> 4.13x ++ 3.70 -> 4.70x +++ > Spring PetClinic Demo 3.24 -> 3.33x + 3.04 -> 3.03x ~ > > (The +, -, ~ are calculated by my eyeballs so not very scientific :-) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5486 bytes Desc: S/MIME Cryptographic Signature URL: From kvn at openjdk.org Thu Oct 2 15:40:24 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 15:40:24 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 08:43:25 GMT, Andrew Dinn wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed card_shift from AOT constants table. Fixed minimal VM build. > > src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 68: > >> 66: >> 67: #ifdef CARDTABLEBARRIERSET_POST_BARRIER_HELPER >> 68: assert(!aotCodeCache::is_on(), "this path is not implemented"); > > Suggestion: > > assert(!AOTCodeCache::is_on(), "this path is not implemented"); Goot catch. 32-bit ARM build failed because of this. > src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 88: > >> 86: __ move(byte_map_base_adr, byte_map_base_reg); >> 87: LIR_Address* byte_map_base_indirect = new LIR_Address(byte_map_base_reg, 0, T_LONG); >> 88: //LIR_Opr byte_map_base = gen->new_pointer_register(); > > Do we need this comment? Removed. I experimented with separate registers but reusing register (byte_map_base_reg) seems work too. ------------- PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2399240598 PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2399246826 From kvn at openjdk.org Thu Oct 2 15:53:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 15:53:31 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 08:50:53 GMT, Andrew Dinn wrote: > I'm not sure why we are seeing a Shenandoah timeout but it ought to be unrelated as Shenandoah barriers are 1) independent of the (G1) region grain size and 2) access the card table base via a thread local. I did not look on Shenandoah barriers - there could be issues there. There test throws OOM: stderr: [Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space 2025-10-02T06:56:37.6700940Z at TestThreadFailure$NastyThread.run(TestThreadFailure.java:49) 2025-10-02T06:56:37.6701860Z Exception in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space 2025-10-02T06:56:37.6702380Z at TestThreadFailure$NastyThread.run(TestThreadFailure.java:49) ------------- PR Comment: https://git.openjdk.org/leyden/pull/102#issuecomment-3361957950 From ioi.lam at oracle.com Thu Oct 2 16:03:03 2025 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 2 Oct 2025 09:03:03 -0700 Subject: Updated benchmark numbers in premain README In-Reply-To: References:

Message-ID: <48c64dc6-3934-45e4-a098-932477398389@oracle.com> Hi Sebastien, if you could help us update the benchmark, that would be great! Thanks - Ioi On 10/2/25 2:52 AM, Sebastien Deleuze wrote: > For the Spring Petclinic demo, I am not sure yet about the reason for > it to be an outlier, but I would suggest to: > ?- Update to a more recent commit than the outdated one (see > https://github.com/openjdk/leyden/blob/premain/test/hotspot/jtreg/premain/spring-petclinic/Makefile#L126) > ?- Leverage the CDS/AOT cache friendly unpacking feature (available as > of Spring Boot 3.3) > https://docs.spring.io/spring-boot/reference/packaging/efficient.html > ?- Use a more production-like arrangement by avoiding creating the > database schema at startup > > Spring-boot Getting Started Demo should be also updated to a more > recent version and use the CDS/AOT cache friendly unpacking feature. > > I suggest we collaborate on that. > > > On Tue, Sep 30, 2025 at 9:49?PM wrote: > > I've updated the benchmark numbers using the latest premain tip > (as of 2025/09/30): > > https://github.com/openjdk/leyden/blob/premain/README.md#premain-aot-cache-summary > > There's quite a bit of improvement due to the new compiler tuning > changes by Aleksey. I also added a "2 cores only" mode to > emulate?microservices that are allocated very few CPUs. > > > Here are the results of {premain AOT} vs {JDK 25, no CDS, no AOT}. > Note that premain is generally much more beneficial with the 2 > Cores Only case, except for PetClinic: > > > Benchmark? ? ? ? Desktop/Server Class (28 Cores)? ?2 Cores Only > *---------------------------------------------------------------------------- > *Helidon Quick Start? ? ? ? ? ? ? ? 3.59x ? ? 4.11x? ++ > JavacBenchApp 50 source files? ? ? 2.21x 3.17x? ++++ > Micronaut First App Demo? ? ? ? ? ?2.91x 4.90x? +++++++ > Quarkus Getting Started Demo? ? ? ?2.97x 3.74x? +++ > Spring-boot Getting Started Demo? ?4.13x 4.70x? ++ > Spring PetClinic Demo? ? ? ? ? ? ? 3.33x 3.03x? -- ??? > > > > Changes from last time ( > https://github.com/openjdk/leyden/blob/46e03d000efd1b2784ad4dcd4c83310ace498ec0/README.md > ) > > The 2 Core Only case see a lot of improvements with the compiler > tuning. PetClinic is again an outlier. > > Benchmark? ? ? ? ? ?Desktop/Server Class (28 Cores)? ?2 Cores Only > ---------------------------------------------------------------------------- > Helidon Quick Start? ? ? ? ? ? ? ? 3.60 -> 3.59x? ~ ? ? 3.53 -> > 4.11x? ++ > JavacBenchApp 50 source files? ? ? 2.17 -> 2.21x? ~ ? ? 2.74 -> > 3.17x? ++ > Micronaut First App Demo? ? ? ? ? ?2.85 -> 2.91x? + ? ? 4.39 -> > 4.90x? ++ > Quarkus Getting Started Demo? ? ? ?2.73 -> 2.97x? ++ ? ?2.95 -> > 3.74x? +++ > Spring-boot Getting Started Demo? ?3.96 -> 4.13x? ++ ? ?3.70 -> > 4.70x? +++ > Spring PetClinic Demo? ? ? ? ? ? ? 3.24 -> 3.33x? + ? ? 3.04 -> > 3.03x? ~ > > (The +, -, ~ are calculated by my eyeballs so not very scientific :-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvn at openjdk.org Thu Oct 2 16:07:23 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 16:07:23 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v3] In-Reply-To: References: Message-ID: > Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L341) > > To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. > > I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/cardTable.cpp#L46) and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. > > @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. > > Changes were testing tier1-5. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Addressed comments ------------- Changes: - all: https://git.openjdk.org/leyden/pull/102/files - new: https://git.openjdk.org/leyden/pull/102/files/e94fb605..469f5f7d Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=102&range=02 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=102&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/leyden/pull/102.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/102/head:pull/102 PR: https://git.openjdk.org/leyden/pull/102 From kvn at openjdk.org Thu Oct 2 16:07:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 16:07:26 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 08:18:31 GMT, Andrew Dinn wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed card_shift from AOT constants table. Fixed minimal VM build. > > src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 48: > >> 46: if (UseCondCardMark) { >> 47: Label L_already_dirty; >> 48: __ ldrb(rscratch2, Address(obj, rscratch)); > > Do we need an extra precondition? > `precond(!UseCondCardMark || rscratch != rscratch2)` added ------------- PR Review Comment: https://git.openjdk.org/leyden/pull/102#discussion_r2399316948 From headius at headius.com Thu Oct 2 16:58:43 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 2 Oct 2025 11:58:43 -0500 Subject: AppCDS in 25 failing for JRuby command line Message-ID: Hello friends! I was doing some testing of AppCDS on JDK 25, in hopes of having our Docker images pre-generate an AppCDS archive. But I discovered an issue... AppCDS does not appear to like the JRuby command line anymore in JDK 25. Here's part of a session where I delete the old AppCDS archive and then run the same command line twice with AutoCreateSharedArchive. The archive generates ok in the first command, but then is rejected by the second command: [] jdk25 $ rm /Users/headius/work/jruby/lib/jruby-java25.jsa [] jdk25 $ /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java @/Users/headius/work/jruby/bin/.jruby.java_opts @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : -Djruby.home=/Users/headius/work/jruby -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main -e 1 [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy13: Unsupported location [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy25: Unsupported location [1.074s][warning][cds] Skipping org/joda/time/field/MillisDurationField: Old class has been linked ... [1.076s][warning][cds] Skipping org/jruby/org/objectweb/asm/ClassWriter: Old class has been linked [1.076s][warning][cds] Skipping org/joda/time/format/DateTimeFormatterBuilder$PaddedNumber: Old class has been linked [] jdk25 $ /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java @/Users/headius/work/jruby/bin/.jruby.java_opts @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : -Djruby.home=/Users/headius/work/jruby -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main -e 1 [0.008s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. [0.008s][error][cds] optimized module handling: disabled because extra module path(s) are specified [0.008s][error][cds] Mismatched values for property jdk.module.enable.native.access: org.jruby.dist specified during runtime but not during dump time [0.008s][error][cds] Disabling optimized module handling [0.008s][error][cds] Mismatched values for property jdk.module.addopens: java.base/java.io =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/ sun.nio.ch=org.jruby.dist,java.management/sun.management=org.jruby.dist specified during runtime but not during dump time [0.008s][error][cds] Disabling optimized module handling The errors make no sense because I'm doing exactly the same thing in both command lines. Here's the contents of the /Users/headius/work/jruby/bin/.jruby.module_opts file (the .jruby.java_opts file is empty): --add-opens java.base/java.io=org.jruby.dist --add-opens java.base/java.nio.channels=org.jruby.dist --add-opens java.base/sun.nio.ch=org.jruby.dist --add-opens java.management/sun.management=org.jruby.dist Running the same commands against JDK 21 works just fine... the jsa file is generated and used correctly. Is there something I'm doing wrong with this command line that JDK 25 does not like? I can re-test with another JDK if necessary. Let me know if I should open a bug for this. Reproduce by downloading JRuby from https://jruby.org and unpacking. It runs out of the box. *Charles Oliver Nutter* *Architect and Technologist* Headius Enterprises https://www.headius.com headius at headius.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From headius at headius.com Thu Oct 2 17:09:07 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 2 Oct 2025 12:09:07 -0500 Subject: AppCDS in 25 failing for JRuby command line In-Reply-To: References:

Message-ID: Full output as a gist: https://gist.github.com/headius/88d91118ef1487b4fbff357fecf06904 On Thu, Oct 2, 2025 at 12:03?PM Charles Oliver Nutter wrote: > Here's the full -Xlog:aot,cds output. Nothing jumps out at me. It seems to > be confused about which modules are specified at dump time, even though the > same command line sees those modules at runtime. > > [0.010s][info][cds] trying to map > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa > [0.010s][info][cds] Opened shared archive file > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa. > [0.010s][info][cds] The shared archive file was created with > UseCompressedOops = 1, UseCompressedClassPointers = 1, > UseCompactObjectHeaders = 0 > [0.010s][info][cds] Core region alignment: 16384 > [0.010s][info][cds] trying to map > /Users/headius/work/jruby/lib/jruby-java25.jsa > [0.010s][info][cds] Opened shared archive file > /Users/headius/work/jruby/lib/jruby-java25.jsa. > [0.010s][info][cds] The shared archive file was created with > UseCompressedOops = 1, UseCompressedClassPointers = 1, > UseCompactObjectHeaders = 0 > [0.010s][info][cds] optimized module handling: disabled because archive > was created without optimized module handling > [0.010s][info][cds] ArchiveRelocationMode: 1 > [0.010s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at > an alternative address > [0.010s][info][cds] Try to map archive(s) at an alternative address > [0.010s][info][cds] Reserved archive_space_rs [0x0000000f00000000 - > 0x0000000f03000000] (50331648) bytes (includes protection zone) > [0.010s][info][cds] Reserved class_space_rs [0x0000000f03000000 - > 0x0000000f43000000] (1073741824) bytes > [0.010s][info][cds] Mapped static region #0 at base 0x0000000f00004000 > top 0x0000000f004b0000 (ReadWrite) > [0.010s][info][cds] Mapped static region #1 at base 0x0000000f004b0000 > top 0x0000000f00d94000 (ReadOnly) > [0.010s][info][cds] Mapped static region #2 at base 0x00000001009d8000 > top 0x0000000100a0c000 (Bitmap) > [0.020s][error][cds] An error has occurred while processing the shared > archive file. Run with -Xlog:aot,cds for details. > [0.020s][error][cds] optimized module handling: disabled because extra > module path(s) are specified > [0.020s][info ][cds] archived module property jdk.module.main: (null) > [0.020s][info ][cds] archived module property jdk.module.addexports: (null) > [0.020s][info ][cds] archived module property jdk.module.addmods: (null) > [0.020s][info ][cds] archived module property > jdk.module.enable.native.access: (null) > [0.020s][error][cds] Mismatched values for property > jdk.module.enable.native.access: org.jruby.dist specified during runtime > but not during dump time > [0.020s][error][cds] Disabling optimized module handling > [0.020s][info ][cds] archived module property jdk.module.addopens: (null) > [0.020s][error][cds] Mismatched values for property jdk.module.addopens: > java.base/java.io > =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/ > sun.nio.ch=org.jruby.dist,java.management/sun.management=org.jruby.dist > specified during runtime but not during dump time > [0.020s][error][cds] Disabling optimized module handling > [0.020s][info ][cds] archived module property jdk.module.addreads: (null) > [0.020s][info ][cds] optimized module handling: disabled > [0.020s][info ][cds] full module graph: disabled > [0.021s][info ][cds] Mapped dynamic region #0 at base 0x0000000f00d94000 > top 0x0000000f01a80000 (ReadWrite) > [0.021s][info ][cds] Mapped dynamic region #1 at base 0x0000000f01a80000 > top 0x0000000f02b4c000 (ReadOnly) > [0.021s][info ][cds] Mapped dynamic region #2 at base 0x0000000101a8c000 > top 0x0000000101afc000 (Bitmap) > [0.025s][info ][cds] CDS archive was created with max heap size = 128M, > and the following configuration: > [0.025s][info ][cds] narrow_klass_base at mapping start address, > narrow_klass_pointer_bits = 32, narrow_klass_shift = 0 > [0.025s][info ][cds] narrow_oop_mode = 1, narrow_oop_base = > 0x0000000000000000, narrow_oop_shift = 3 > [0.025s][info ][cds] The current max heap size = 6144M, > G1HeapRegion::GrainBytes = 4194304 > [0.025s][info ][cds] narrow_klass_base = 0x0000000f00000000, > arrow_klass_pointer_bits = 32, narrow_klass_shift = 0 > [0.025s][info ][cds] narrow_oop_mode = 1, narrow_oop_base = > 0x0000000000000000, narrow_oop_shift = 3 > [0.025s][info ][cds] heap range = [0x0000000680000000 - > 0x0000000800000000] > [0.025s][info ][cds] Preferred address to map heap data (to avoid > relocation) is 0x00000007ffe00000 > [0.025s][info ][cds] Heap data mapped at 0x00000007ffc00000, size = > 1177848 bytes > [0.025s][info ][cds] CDS heap data relocation delta = -2097152 bytes > [0.025s][info ][aot] initial optimized module handling: disabled > [0.025s][info ][aot] initial full module graph: disabled > [0.025s][info ][aot] patching heap embedded pointers: narrowOop 0xfffc0000 > -> 0xfff80000 > [0.025s][info ][aot] heap data relocation quick delta = 0xfffc0000 > [0.027s][info ][cds] Unmapping region #2 at base 0x00000001009d8000 > (Bitmap) > [0.027s][info ][cds] Unmapping region #2 at base 0x0000000101a8c000 > (Bitmap) > [0.027s][info ][aot] Using AOT-linked classes: false (static archive: no > aot-linked classes, dynamic archive: no aot-linked classes) > > On Thu, Oct 2, 2025 at 11:58?AM Charles Oliver Nutter > wrote: > >> Hello friends! >> >> I was doing some testing of AppCDS on JDK 25, in hopes of having our >> Docker images pre-generate an AppCDS archive. But I discovered an issue... >> AppCDS does not appear to like the JRuby command line anymore in JDK 25. >> >> Here's part of a session where I delete the old AppCDS archive and then >> run the same command line twice with AutoCreateSharedArchive. The archive >> generates ok in the first command, but then is rejected by the second >> command: >> >> [] jdk25 $ rm /Users/headius/work/jruby/lib/jruby-java25.jsa >> [] jdk25 $ >> /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java >> @/Users/headius/work/jruby/bin/.jruby.java_opts >> @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k >> -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni >> -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive >> -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa >> --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow >> --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : >> -Djruby.home=/Users/headius/work/jruby >> -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby >> -Djruby.shell=/bin/sh org.jruby.Main -e 1 >> [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy13: Unsupported location >> [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy25: Unsupported location >> [1.074s][warning][cds] Skipping org/joda/time/field/MillisDurationField: >> Old class has been linked >> ... >> [1.076s][warning][cds] Skipping org/jruby/org/objectweb/asm/ClassWriter: >> Old class has been linked >> [1.076s][warning][cds] Skipping >> org/joda/time/format/DateTimeFormatterBuilder$PaddedNumber: Old class has >> been linked >> [] jdk25 $ >> /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java >> @/Users/headius/work/jruby/bin/.jruby.java_opts >> @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k >> -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni >> -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive >> -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa >> --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow >> --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : >> -Djruby.home=/Users/headius/work/jruby >> -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby >> -Djruby.shell=/bin/sh org.jruby.Main -e 1 >> [0.008s][error][cds] An error has occurred while processing the shared >> archive file. Run with -Xlog:aot,cds for details. >> [0.008s][error][cds] optimized module handling: disabled because extra >> module path(s) are specified >> [0.008s][error][cds] Mismatched values for property >> jdk.module.enable.native.access: org.jruby.dist specified during runtime >> but not during dump time >> [0.008s][error][cds] Disabling optimized module handling >> [0.008s][error][cds] Mismatched values for property jdk.module.addopens: >> java.base/java.io >> =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/ >> sun.nio.ch=org.jruby.dist,java.management/sun.management=org.jruby.dist >> specified during runtime but not during dump time >> [0.008s][error][cds] Disabling optimized module handling >> >> The errors make no sense because I'm doing exactly the same thing in both >> command lines. >> >> Here's the contents of the >> /Users/headius/work/jruby/bin/.jruby.module_opts file (the .jruby.java_opts >> file is empty): >> >> --add-opens java.base/java.io=org.jruby.dist >> --add-opens java.base/java.nio.channels=org.jruby.dist >> --add-opens java.base/sun.nio.ch=org.jruby.dist >> --add-opens java.management/sun.management=org.jruby.dist >> >> Running the same commands against JDK 21 works just fine... the jsa file >> is generated and used correctly. Is there something I'm doing wrong with >> this command line that JDK 25 does not like? >> >> I can re-test with another JDK if necessary. Let me know if I should open >> a bug for this. >> >> Reproduce by downloading JRuby from https://jruby.org and unpacking. It >> runs out of the box. >> >> *Charles Oliver Nutter* >> *Architect and Technologist* >> Headius Enterprises >> https://www.headius.com >> headius at headius.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From headius at headius.com Thu Oct 2 17:03:15 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 2 Oct 2025 12:03:15 -0500 Subject: AppCDS in 25 failing for JRuby command line In-Reply-To: References: Message-ID: Here's the full -Xlog:aot,cds output. Nothing jumps out at me. It seems to be confused about which modules are specified at dump time, even though the same command line sees those modules at runtime. [0.010s][info][cds] trying to map /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa [0.010s][info][cds] Opened shared archive file /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa. [0.010s][info][cds] The shared archive file was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 0 [0.010s][info][cds] Core region alignment: 16384 [0.010s][info][cds] trying to map /Users/headius/work/jruby/lib/jruby-java25.jsa [0.010s][info][cds] Opened shared archive file /Users/headius/work/jruby/lib/jruby-java25.jsa. [0.010s][info][cds] The shared archive file was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 0 [0.010s][info][cds] optimized module handling: disabled because archive was created without optimized module handling [0.010s][info][cds] ArchiveRelocationMode: 1 [0.010s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address [0.010s][info][cds] Try to map archive(s) at an alternative address [0.010s][info][cds] Reserved archive_space_rs [0x0000000f00000000 - 0x0000000f03000000] (50331648) bytes (includes protection zone) [0.010s][info][cds] Reserved class_space_rs [0x0000000f03000000 - 0x0000000f43000000] (1073741824) bytes [0.010s][info][cds] Mapped static region #0 at base 0x0000000f00004000 top 0x0000000f004b0000 (ReadWrite) [0.010s][info][cds] Mapped static region #1 at base 0x0000000f004b0000 top 0x0000000f00d94000 (ReadOnly) [0.010s][info][cds] Mapped static region #2 at base 0x00000001009d8000 top 0x0000000100a0c000 (Bitmap) [0.020s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. [0.020s][error][cds] optimized module handling: disabled because extra module path(s) are specified [0.020s][info ][cds] archived module property jdk.module.main: (null) [0.020s][info ][cds] archived module property jdk.module.addexports: (null) [0.020s][info ][cds] archived module property jdk.module.addmods: (null) [0.020s][info ][cds] archived module property jdk.module.enable.native.access: (null) [0.020s][error][cds] Mismatched values for property jdk.module.enable.native.access: org.jruby.dist specified during runtime but not during dump time [0.020s][error][cds] Disabling optimized module handling [0.020s][info ][cds] archived module property jdk.module.addopens: (null) [0.020s][error][cds] Mismatched values for property jdk.module.addopens: java.base/java.io =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/ sun.nio.ch=org.jruby.dist,java.management/sun.management=org.jruby.dist specified during runtime but not during dump time [0.020s][error][cds] Disabling optimized module handling [0.020s][info ][cds] archived module property jdk.module.addreads: (null) [0.020s][info ][cds] optimized module handling: disabled [0.020s][info ][cds] full module graph: disabled [0.021s][info ][cds] Mapped dynamic region #0 at base 0x0000000f00d94000 top 0x0000000f01a80000 (ReadWrite) [0.021s][info ][cds] Mapped dynamic region #1 at base 0x0000000f01a80000 top 0x0000000f02b4c000 (ReadOnly) [0.021s][info ][cds] Mapped dynamic region #2 at base 0x0000000101a8c000 top 0x0000000101afc000 (Bitmap) [0.025s][info ][cds] CDS archive was created with max heap size = 128M, and the following configuration: [0.025s][info ][cds] narrow_klass_base at mapping start address, narrow_klass_pointer_bits = 32, narrow_klass_shift = 0 [0.025s][info ][cds] narrow_oop_mode = 1, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 3 [0.025s][info ][cds] The current max heap size = 6144M, G1HeapRegion::GrainBytes = 4194304 [0.025s][info ][cds] narrow_klass_base = 0x0000000f00000000, arrow_klass_pointer_bits = 32, narrow_klass_shift = 0 [0.025s][info ][cds] narrow_oop_mode = 1, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 3 [0.025s][info ][cds] heap range = [0x0000000680000000 - 0x0000000800000000] [0.025s][info ][cds] Preferred address to map heap data (to avoid relocation) is 0x00000007ffe00000 [0.025s][info ][cds] Heap data mapped at 0x00000007ffc00000, size = 1177848 bytes [0.025s][info ][cds] CDS heap data relocation delta = -2097152 bytes [0.025s][info ][aot] initial optimized module handling: disabled [0.025s][info ][aot] initial full module graph: disabled [0.025s][info ][aot] patching heap embedded pointers: narrowOop 0xfffc0000 -> 0xfff80000 [0.025s][info ][aot] heap data relocation quick delta = 0xfffc0000 [0.027s][info ][cds] Unmapping region #2 at base 0x00000001009d8000 (Bitmap) [0.027s][info ][cds] Unmapping region #2 at base 0x0000000101a8c000 (Bitmap) [0.027s][info ][aot] Using AOT-linked classes: false (static archive: no aot-linked classes, dynamic archive: no aot-linked classes) On Thu, Oct 2, 2025 at 11:58?AM Charles Oliver Nutter wrote: > Hello friends! > > I was doing some testing of AppCDS on JDK 25, in hopes of having our > Docker images pre-generate an AppCDS archive. But I discovered an issue... > AppCDS does not appear to like the JRuby command line anymore in JDK 25. > > Here's part of a session where I delete the old AppCDS archive and then > run the same command line twice with AutoCreateSharedArchive. The archive > generates ok in the first command, but then is rejected by the second > command: > > [] jdk25 $ rm /Users/headius/work/jruby/lib/jruby-java25.jsa > [] jdk25 $ > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java > @/Users/headius/work/jruby/bin/.jruby.java_opts > @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k > -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni > -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive > -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa > --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow > --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : > -Djruby.home=/Users/headius/work/jruby > -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby > -Djruby.shell=/bin/sh org.jruby.Main -e 1 > [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy13: Unsupported location > [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy25: Unsupported location > [1.074s][warning][cds] Skipping org/joda/time/field/MillisDurationField: > Old class has been linked > ... > [1.076s][warning][cds] Skipping org/jruby/org/objectweb/asm/ClassWriter: > Old class has been linked > [1.076s][warning][cds] Skipping > org/joda/time/format/DateTimeFormatterBuilder$PaddedNumber: Old class has > been linked > [] jdk25 $ > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java > @/Users/headius/work/jruby/bin/.jruby.java_opts > @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k > -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni > -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive > -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa > --enable-native-access=org.jruby.dist --sun-misc-unsafe-memory-access=allow > --module-path /Users/headius/work/jruby/lib/jruby.jar -classpath : > -Djruby.home=/Users/headius/work/jruby > -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby > -Djruby.shell=/bin/sh org.jruby.Main -e 1 > [0.008s][error][cds] An error has occurred while processing the shared > archive file. Run with -Xlog:aot,cds for details. > [0.008s][error][cds] optimized module handling: disabled because extra > module path(s) are specified > [0.008s][error][cds] Mismatched values for property > jdk.module.enable.native.access: org.jruby.dist specified during runtime > but not during dump time > [0.008s][error][cds] Disabling optimized module handling > [0.008s][error][cds] Mismatched values for property jdk.module.addopens: > java.base/java.io > =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/ > sun.nio.ch=org.jruby.dist,java.management/sun.management=org.jruby.dist > specified during runtime but not during dump time > [0.008s][error][cds] Disabling optimized module handling > > The errors make no sense because I'm doing exactly the same thing in both > command lines. > > Here's the contents of the > /Users/headius/work/jruby/bin/.jruby.module_opts file (the .jruby.java_opts > file is empty): > > --add-opens java.base/java.io=org.jruby.dist > --add-opens java.base/java.nio.channels=org.jruby.dist > --add-opens java.base/sun.nio.ch=org.jruby.dist > --add-opens java.management/sun.management=org.jruby.dist > > Running the same commands against JDK 21 works just fine... the jsa file > is generated and used correctly. Is there something I'm doing wrong with > this command line that JDK 25 does not like? > > I can re-test with another JDK if necessary. Let me know if I should open > a bug for this. > > Reproduce by downloading JRuby from https://jruby.org and unpacking. It > runs out of the box. > > *Charles Oliver Nutter* > *Architect and Technologist* > Headius Enterprises > https://www.headius.com > headius at headius.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at openjdk.org Thu Oct 2 21:41:21 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Oct 2025 21:41:21 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v3] In-Reply-To: References:

Message-ID: <8iaSlwPuGvvhup7sn01hKxfAscmb82z4viTmqBahDiI=.340a6b89-2816-448e-beb4-a9df2d5b0055@github.com> On Thu, 2 Oct 2025 16:07:23 GMT, Vladimir Kozlov wrote: >> Currently we use `Relocation` info to patch `card_table::_byte_map_base` referenced in compiled code. This is not completely correct since this is not address. We currently have special check in `AOTCodeCache::init2()` to skip AOT code generation and usage if `byte_map_base` is not relocatable [aotCodeCache.cpp#L341](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L341) >> >> To avoid this we should use existing `AOTRuntimeConstants` table to load `byte_map_base` from it. >> >> I also added few missing loads `card_shift` from `AOTRuntimeConstants` table. Actually I am not sure why we have it in `AOTRuntimeConstants` table. From what I see, it is based on `GCCardSizeInBytes` flag [cardTable.cpp#L46](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/cardTable.cpp#L46) and never modified. The flags is not adjusted ergonomically. So we can simple record the flag in AOT code configuration and verify it when loading AOT code. >> >> @adinn what do you think about `card_shift` in `AOTRuntimeConstants` table? You added it there. >> >> Changes were testing tier1-5. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Addressed comments Still looks good. ------------- PR Comment: https://git.openjdk.org/leyden/pull/102#issuecomment-3363244920 From kvn at openjdk.org Thu Oct 2 21:47:21 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Oct 2025 21:47:21 GMT Subject: RFR: 8368811: [Leyden] Use AOTRuntimeConstants table for card_table::_byte_map_base [v3] In-Reply-To: <8iaSlwPuGvvhup7sn01hKxfAscmb82z4viTmqBahDiI=.340a6b89-2816-448e-beb4-a9df2d5b0055@github.com> References:

<8iaSlwPuGvvhup7sn01hKxfAscmb82z4viTmqBahDiI=.340a6b89-2816-448e-beb4-a9df2d5b0055@github.com> Message-ID: <2qTwBCjxf_I_mvPPdezQJueUXbuk6S_umuMCXWhtYtI=.8f0fc12f-d64f-4b7e-a20e-5c5052408d84@github.com> On Thu, 2 Oct 2025 21:38:18 GMT, Andrew Dinn wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed comments > > Still looks good. Thank you @adinn I will wait for Ioi's mainline merge to premain to integrate this. ------------- PR Comment: https://git.openjdk.org/leyden/pull/102#issuecomment-3363314081 From ioi.lam at oracle.com Thu Oct 2 22:47:56 2025 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Thu, 2 Oct 2025 15:47:56 -0700 Subject: AppCDS in 25 failing for JRuby command line In-Reply-To: References:

Message-ID: <354af059-e684-4278-8010-8221eabe33d0@oracle.com> Hi Charlie, > [] jdk25 $ rm /Users/headius/work/jruby/lib/jruby-java25.jsa > [] jdk25 $ > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java > @/Users/headius/work/jruby/bin/.jruby.java_opts > @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k > -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni > -Djava.security.egd=file:/dev/urandom -XX:+AutoCreateSharedArchive > -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa > --enable-native-access=org.jruby.dist > --sun-misc-unsafe-memory-access=allow --module-path > /Users/headius/work/jruby/lib/jruby.jar -classpath : > -Djruby.home=/Users/headius/work/jruby > -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby > -Djruby.shell=/bin/sh org.jruby.Main -e 1 The problem here is -XX:+AutoCreateSharedArchive is for creating a dynamic CDS archive, which runs on top of the static CDS archive that comes with the JDK. The archived module graph is created only for the static CDS archive (or JEP 483 AOT cache). It's not created for the dynamic CDS archive. This is because the archived module graph requires the archiving of Java heap objects, which is not supported by the dynamic archive. The errors you saw basically meant that because different parameters were given for?--module-path, --enable-native-access, etc, than those used when we created the default CDS archive, we are not able to use the archived module graph. This is a performance regression from JDK 24, as the archived module graph would have also been disabled with JDK 24. However, in JDK 25, we changed the logging of these messages so they are now printed in the "error" channel. This is a bug. I have created https://bugs.openjdk.org/browse/JDK-8369079 and will try to backport the fix to JDK 25u. Meanwhile, you can add -Xlog:cds=none to disable these logs. A better alternative would be to use the AOT cache. It will have faster start-up time, and it will store an?archived module graph that matches your command-line settings. Thanks - Ioi On 10/2/25 10:09 AM, Charles Oliver Nutter wrote: > Full output as a gist: > https://gist.github.com/headius/88d91118ef1487b4fbff357fecf06904 > > On Thu, Oct 2, 2025 at 12:03?PM Charles Oliver Nutter > wrote: > > Here's the full -Xlog:aot,cds output. Nothing jumps out at me. It > seems to be confused about which modules are specified at dump > time, even though the same command line sees those modules at > runtime. > > [0.010s][info][cds] trying to map > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa > [0.010s][info][cds] Opened shared archive file > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/lib/server/classes.jsa. > [0.010s][info][cds] The shared archive file was created with > UseCompressedOops = 1, UseCompressedClassPointers = 1, > UseCompactObjectHeaders = 0 > [0.010s][info][cds] Core region alignment: 16384 > [0.010s][info][cds] trying to map > /Users/headius/work/jruby/lib/jruby-java25.jsa > [0.010s][info][cds] Opened shared archive file > /Users/headius/work/jruby/lib/jruby-java25.jsa. > [0.010s][info][cds] The shared archive file was created with > UseCompressedOops = 1, UseCompressedClassPointers = 1, > UseCompactObjectHeaders = 0 > [0.010s][info][cds] optimized module handling: disabled because > archive was created without optimized module handling > [0.010s][info][cds] ArchiveRelocationMode: 1 > [0.010s][info][cds] ArchiveRelocationMode == 1: always map > archive(s) at an alternative address > [0.010s][info][cds] Try to map archive(s) at an alternative address > [0.010s][info][cds] Reserved archive_space_rs [0x0000000f00000000 > - 0x0000000f03000000] (50331648) bytes (includes protection zone) > [0.010s][info][cds] Reserved class_space_rs [0x0000000f03000000 - > 0x0000000f43000000] (1073741824) bytes > [0.010s][info][cds] Mapped static ?region #0 at base > 0x0000000f00004000 top 0x0000000f004b0000 (ReadWrite) > [0.010s][info][cds] Mapped static ?region #1 at base > 0x0000000f004b0000 top 0x0000000f00d94000 (ReadOnly) > [0.010s][info][cds] Mapped static ?region #2 at base > 0x00000001009d8000 top 0x0000000100a0c000 (Bitmap) > [0.020s][error][cds] An error has occurred while processing the > shared archive file. Run with -Xlog:aot,cds for details. > [0.020s][error][cds] optimized module handling: disabled because > extra module path(s) are specified > [0.020s][info ][cds] archived module property jdk.module.main: (null) > [0.020s][info ][cds] archived module property > jdk.module.addexports: (null) > [0.020s][info ][cds] archived module property jdk.module.addmods: > (null) > [0.020s][info ][cds] archived module property > jdk.module.enable.native.access: (null) > [0.020s][error][cds] Mismatched values for property > jdk.module.enable.native.access: org.jruby.dist specified during > runtime but not during dump time > [0.020s][error][cds] Disabling optimized module handling > [0.020s][info ][cds] archived module property jdk.module.addopens: > (null) > [0.020s][error][cds] Mismatched values for property > jdk.module.addopens: java.base/java.io > =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/sun.nio.ch > =org.jruby.dist,java.management/sun.management=org.jruby.dist > specified during runtime but not during dump time > [0.020s][error][cds] Disabling optimized module handling > [0.020s][info ][cds] archived module property jdk.module.addreads: > (null) > [0.020s][info ][cds] optimized module handling: disabled > [0.020s][info ][cds] full module graph: disabled > [0.021s][info ][cds] Mapped dynamic region #0 at base > 0x0000000f00d94000 top 0x0000000f01a80000 (ReadWrite) > [0.021s][info ][cds] Mapped dynamic region #1 at base > 0x0000000f01a80000 top 0x0000000f02b4c000 (ReadOnly) > [0.021s][info ][cds] Mapped dynamic region #2 at base > 0x0000000101a8c000 top 0x0000000101afc000 (Bitmap) > [0.025s][info ][cds] CDS archive was created with max heap size = > 128M, and the following configuration: > [0.025s][info ][cds] ? ? narrow_klass_base at mapping start > address, narrow_klass_pointer_bits = 32, narrow_klass_shift = 0 > [0.025s][info ][cds] ? ? narrow_oop_mode = 1, narrow_oop_base = > 0x0000000000000000, narrow_oop_shift = 3 > [0.025s][info ][cds] The current max heap size = 6144M, > G1HeapRegion::GrainBytes = 4194304 > [0.025s][info ][cds] ? ? narrow_klass_base = 0x0000000f00000000, > arrow_klass_pointer_bits = 32, narrow_klass_shift = 0 > [0.025s][info ][cds] ? ? narrow_oop_mode = 1, narrow_oop_base = > 0x0000000000000000, narrow_oop_shift = 3 > [0.025s][info ][cds] ? ? heap range = [0x0000000680000000 - > 0x0000000800000000] > [0.025s][info ][cds] Preferred address to map heap data (to avoid > relocation) is 0x00000007ffe00000 > [0.025s][info ][cds] Heap data mapped at 0x00000007ffc00000, size > = ?1177848 bytes > [0.025s][info ][cds] CDS heap data relocation delta = -2097152 bytes > [0.025s][info ][aot] initial optimized module handling: disabled > [0.025s][info ][aot] initial full module graph: disabled > [0.025s][info ][aot] patching heap embedded pointers: narrowOop > 0xfffc0000 -> 0xfff80000 > [0.025s][info ][aot] heap data relocation quick delta = 0xfffc0000 > [0.027s][info ][cds] Unmapping region #2 at base > 0x00000001009d8000 (Bitmap) > [0.027s][info ][cds] Unmapping region #2 at base > 0x0000000101a8c000 (Bitmap) > [0.027s][info ][aot] Using AOT-linked classes: false (static > archive: no aot-linked classes, dynamic archive: no aot-linked > classes) > > On Thu, Oct 2, 2025 at 11:58?AM Charles Oliver Nutter > wrote: > > Hello friends! > > I was doing some testing of AppCDS on JDK 25, in hopes of > having our Docker images pre-generate an AppCDS archive. But I > discovered an issue... AppCDS does not appear to like the > JRuby command line anymore in JDK 25. > > Here's part of a session where I delete the old AppCDS archive > and then run the same command line twice > with?AutoCreateSharedArchive. The archive generates ok in the > first command, but then is rejected by the second command: > > [] jdk25 $ rm /Users/headius/work/jruby/lib/jruby-java25.jsa > [] jdk25 $ > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java > @/Users/headius/work/jruby/bin/.jruby.java_opts > @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k > -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni > -Djava.security.egd=file:/dev/urandom > -XX:+AutoCreateSharedArchive > -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa > --enable-native-access=org.jruby.dist > --sun-misc-unsafe-memory-access=allow --module-path > /Users/headius/work/jruby/lib/jruby.jar -classpath : > -Djruby.home=/Users/headius/work/jruby > -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby > -Djruby.shell=/bin/sh org.jruby.Main -e 1 > [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy13: > Unsupported location > [1.074s][warning][cds] Skipping jdk/proxy2/$Proxy25: > Unsupported location > [1.074s][warning][cds] Skipping > org/joda/time/field/MillisDurationField: Old class has been linked > ... > [1.076s][warning][cds] Skipping > org/jruby/org/objectweb/asm/ClassWriter: Old class has been linked > [1.076s][warning][cds] Skipping > org/joda/time/format/DateTimeFormatterBuilder$PaddedNumber: > Old class has been linked > [] jdk25 $ > /Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/bin/java > @/Users/headius/work/jruby/bin/.jruby.java_opts > @/Users/headius/work/jruby/bin/.jruby.module_opts -Xss2048k > -Djffi.boot.library.path=/Users/headius/work/jruby/lib/jni > -Djava.security.egd=file:/dev/urandom > -XX:+AutoCreateSharedArchive > -XX:SharedArchiveFile=/Users/headius/work/jruby/lib/jruby-java25.jsa > --enable-native-access=org.jruby.dist > --sun-misc-unsafe-memory-access=allow --module-path > /Users/headius/work/jruby/lib/jruby.jar -classpath : > -Djruby.home=/Users/headius/work/jruby > -Djruby.lib=/Users/headius/work/jruby/lib -Djruby.script=jruby > -Djruby.shell=/bin/sh org.jruby.Main -e 1 > [0.008s][error][cds] An error has occurred while processing > the shared archive file. Run with -Xlog:aot,cds for details. > [0.008s][error][cds] optimized module handling: disabled > because extra module path(s) are specified > [0.008s][error][cds] Mismatched values for property > jdk.module.enable.native.access: org.jruby.dist specified > during runtime but not during dump time > [0.008s][error][cds] Disabling optimized module handling > [0.008s][error][cds] Mismatched values for property > jdk.module.addopens: java.base/java.io > =org.jruby.dist,java.base/java.nio.channels=org.jruby.dist,java.base/sun.nio.ch > =org.jruby.dist,java.management/sun.management=org.jruby.dist > specified during runtime but not during dump time > [0.008s][error][cds] Disabling optimized module handling > > The errors make no sense because I'm doing exactly the same > thing in both command lines. > > Here's the contents of the > /Users/headius/work/jruby/bin/.jruby.module_opts file (the > .jruby.java_opts file is empty): > > --add-opens java.base/java.io =org.jruby.dist > --add-opens java.base/java.nio.channels=org.jruby.dist > --add-opens java.base/sun.nio.ch > =org.jruby.dist > --add-opens java.management/sun.management=org.jruby.dist > > Running the same commands against JDK 21 works just fine... > the jsa file is generated and used correctly. Is there > something I'm doing wrong with this command line that JDK 25 > does not like? > > I can re-test with another JDK if necessary. Let me know if I > should open a bug for this. > > Reproduce by downloading JRuby from https://jruby.org and > unpacking. It runs out of the box. > > *Charles Oliver Nutter* > /Architect and Technologist/ > Headius Enterprises > https://www.headius.com > headius at headius.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bylokhov at amazon.com Thu Oct 2 23:40:00 2025 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Thu, 2 Oct 2025 16:40:00 -0700 Subject: bye stable values, enter lazy constants In-Reply-To: References: <0c1214f6-c4e5-44c1-b04b-330e38ff41a2@amazon.com> <015c85a4-d117-4b32-9e56-9fb458d7d16f@oracle.com> <033cfbd1-d6c8-4bf4-9f54-c9b7e85c5b89@oracle.com> <39b68d9b-7eeb-4c12-aac3-dd85d5f6a01f@amazon.com>

<2a7191e7-097b-4696-a37e-70c63092464b@oracle.com> <6765d990-d07a-43da-a118-c626ad9d4f4e@amazon.com> Message-ID: <2b65d342-73a3-4603-a6f5-a0d281062a9f@amazon.com> On 10/2/25 01:17, Maurizio Cimadamore wrote: > Yep. Thinking more about this, if we ever did the idea you suggested the > other day (e.g. declaring static fields inside a method), then you could > have tighter scoping > > e.g. > > ``` > Logger getLogger() { > ??? static LazyConstant LOGGER = LazyConstant.of(...); > ??? return LOGGER.get(); > } > ``` > > (Now, while I think it's useful to have static _classes_ inside a > method, I think having a static field in there might be a bit confusing, > as it looks like a local variable, but isn't really -- it's a field. So > whether that's a good idea or not will have to be assessed separately) Note that using LazyConstant in the example above is actually unnecessary, a simpler version works just as well: Logger getLogger() { static Logger LOGGER = ...; return LOGGER; } So, if there are any plans to implement this in the future, we should ensure it does not duplicate what LazyConstant provides. It is possible that the new static local variables combined with the new VarHandle access modes will cover most use cases or we can fit LazyConstant somewhere in between. -- Best regards, Sergey. From iklam at openjdk.org Fri Oct 3 01:02:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 3 Oct 2025 01:02:38 GMT Subject: git: openjdk/leyden: premain: 166 new changesets Message-ID: Changeset: 85996572 Branch: premain Author: Chen Liang Date: 2025-09-10 21:23:45 +0000 URL: https://git.openjdk.org/leyden/commit/85996572b61e789d7e45bd26b23d233a0a41e158 8365676: javac incorrectly allows calling interface static method via type variable Co-authored-by: Maurizio Cimadamore Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/generics/typevars/8365676/T8365676.java + test/langtools/tools/javac/generics/typevars/8365676/T8365676.out Changeset: 7fcce270 Branch: premain Author: William Kemper Date: 2025-09-10 22:12:04 +0000 URL: https://git.openjdk.org/leyden/commit/7fcce27096605a27ca3b74349d1012bb0bd5963d 8365956: GenShen: Adaptive tenuring threshold algorithm may raise threshold prematurely Reviewed-by: kdnilsen, phh ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp ! src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.hpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp + src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.inline.hpp + test/hotspot/gtest/gc/shenandoah/test_shenandoahAgeCensus.cpp Changeset: 134c3ef4 Branch: premain Author: Dingli Zhang Committer: Fei Yang Date: 2025-09-11 00:05:02 +0000 URL: https://git.openjdk.org/leyden/commit/134c3ef41e774b483bcce32ce2fe0ef416017728 8367293: RISC-V: enable vectorapi test for VectorMask.laneIsSet Reviewed-by: fyang, epeter ! test/hotspot/jtreg/compiler/vectorapi/VectorMaskLaneIsSetTest.java Changeset: eb9e0459 Branch: premain Author: Phil Race Date: 2025-09-11 04:59:07 +0000 URL: https://git.openjdk.org/leyden/commit/eb9e04598db7a70347ada005035644012026f902 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out Reviewed-by: psadhukhan ! test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java Changeset: 4cc75be8 Branch: premain Author: Emanuel Peter Date: 2025-09-11 05:03:21 +0000 URL: https://git.openjdk.org/leyden/commit/4cc75be80e6a89e0ed293e2f8bbb6d0f94189468 8366702: C2 SuperWord: refactor VTransform vector nodes Reviewed-by: chagedorn, galder ! src/hotspot/share/opto/superwordVTransformBuilder.cpp ! src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/opto/vtransform.cpp ! src/hotspot/share/opto/vtransform.hpp Changeset: 2826d170 Branch: premain Author: Emanuel Peter Date: 2025-09-11 05:05:30 +0000 URL: https://git.openjdk.org/leyden/commit/2826d1702534783023802ac5c8d8ea575558f09f 8367243: Format issues with dist dump debug output in PhaseGVN::dead_loop_check Reviewed-by: thartmann ! src/hotspot/share/opto/phaseX.cpp Changeset: 7690a45f Branch: premain Author: Mikhail Yankelevich Date: 2025-09-11 06:55:32 +0000 URL: https://git.openjdk.org/leyden/commit/7690a45f77a2da47fa912fe7a2b2faa589f259f0 8366342: Key generator and key pair generator tests skipping, but showing as passed Reviewed-by: weijun ! test/jdk/sun/security/pkcs11/KeyGenerator/DESParity.java ! test/jdk/sun/security/pkcs11/KeyGenerator/TestAES.java ! test/jdk/sun/security/pkcs11/KeyGenerator/TestChaCha20.java ! test/jdk/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ! test/jdk/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java ! test/jdk/sun/security/pkcs11/KeyPairGenerator/TestDefaultDHPrivateExpSize.java Changeset: 8ba0db0d Branch: premain Author: Johan Sj?len Date: 2025-09-11 07:42:39 +0000 URL: https://git.openjdk.org/leyden/commit/8ba0db0de8b79f64cbfa56683f660f888c880182 8366951: Test runtime/logging/StressAsyncUL.java is timing out Reviewed-by: ayang, lkorinth, dholmes, syan ! test/hotspot/jtreg/runtime/logging/StressAsyncUL.java Changeset: 0b3a3030 Branch: premain Author: Hamlin Li Date: 2025-09-11 08:07:25 +0000 URL: https://git.openjdk.org/leyden/commit/0b3a303053d0eb5a98ed3d9df42c659db148b470 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad Changeset: 3d679087 Branch: premain Author: Joel Sikstr?m Date: 2025-09-11 08:53:09 +0000 URL: https://git.openjdk.org/leyden/commit/3d679087b0376c221d536780cee387dc2dd8019e 8367268: Remove unused os::numa_topology_changed() Reviewed-by: ayang, dholmes ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 3355a9d3 Branch: premain Author: Jan Lahoda Date: 2025-09-11 10:43:25 +0000 URL: https://git.openjdk.org/leyden/commit/3355a9d3fa3e57d489f716ebc1c885c1391274ea 8285150: Improve tab completion for annotations Reviewed-by: liach ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java ! test/langtools/jdk/jshell/ToolTabSnippetTest.java Changeset: 063f970f Branch: premain Author: Albert Mingkun Yang Date: 2025-09-11 11:22:12 +0000 URL: https://git.openjdk.org/leyden/commit/063f970f0f5e851d72dad0112735692761d6ba36 8367401: Parallel: Remove unused field in PSKeepAliveClosure Reviewed-by: stefank, fandreuzzi ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: a2d272a0 Branch: premain Author: Albert Mingkun Yang Date: 2025-09-11 11:22:29 +0000 URL: https://git.openjdk.org/leyden/commit/a2d272a02a079e2413d10ad2decb04681ce2f961 8367339: Parallel: Remove PSScavenge::should_scavenge Reviewed-by: tschatzl, fandreuzzi ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/parallel/psScavenge.hpp - src/hotspot/share/gc/parallel/psScavenge.inline.hpp Changeset: 56f2f7a3 Branch: premain Author: Roger Riggs Date: 2025-09-11 13:22:20 +0000 URL: https://git.openjdk.org/leyden/commit/56f2f7a3af0574357d5d3f99dcd908721ac710e9 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c Reviewed-by: bpb, naoto, jpai, lancea ! src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c Changeset: 4ea8979b Branch: premain Author: Artur Barashev Date: 2025-09-11 13:53:08 +0000 URL: https://git.openjdk.org/leyden/commit/4ea8979b93f80e9ecbc197ee12ceb523ef8da6aa 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession Reviewed-by: djelinski, wetmore ! src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java ! test/jdk/sun/security/ssl/X509KeyManager/AlgorithmConstraintsCheck.java + test/jdk/sun/security/ssl/X509KeyManager/NonExtendedSSLSessionAlgorithmConstraints.java Changeset: 781f2b2f Branch: premain Author: Pasam Soujanya Committer: Hannes Walln?fer Date: 2025-09-11 13:58:51 +0000 URL: https://git.openjdk.org/leyden/commit/781f2b2f8188c02a6af220ebcc5bc8158fe8423e 8366278: Form control element