From dholmes at openjdk.org  Mon Sep  1 04:34:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 04:34:48 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

I would suggest filing a new bug for the CentOS hang and create a new PR of the change here, with that new bug ID.

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3240826588

From dholmes at openjdk.org  Mon Sep  1 04:46:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 04:46:49 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v4]
In-Reply-To: <KlKYfOCdt3BRQzlumgqblAec2VV9oJnt9bZ_ca8Nb_c=.bde9b177-a8ac-4043-b363-3225b89a7674@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <KlKYfOCdt3BRQzlumgqblAec2VV9oJnt9bZ_ca8Nb_c=.bde9b177-a8ac-4043-b363-3225b89a7674@github.com>
Message-ID: <jnsthDEUCyCPMAdTdOiIKQjUKsdZ_1K5oJUPGD2gKOk=.e046d6fb-7251-4e1d-9854-01569d440200@github.com>

On Fri, 29 Aug 2025 13:46:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved tests and messages.

A further tweak to the error messages. Thanks

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

> 2427:         if (MinHeapFreeRatio > (uintx)(dmaxf * 100)) {
> 2428:           jio_fprintf(defaultStream::error_stream(),
> 2429:                       "-Xmaxf value (%s) which is also used for MaxHeapFreeRatio must be greater than or equal to MinHeapFreeRatio (%3.2lf)\n",

Suggestion:

                      "-Xmaxf value (%s) must be greater than or equal to the implicit -Xminf value (%3.2lf)\n",

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

> 2453:         if (MaxHeapFreeRatio < (uintx)(dminf * 100)) {
> 2454:           jio_fprintf(defaultStream::error_stream(),
> 2455:                       "-Xminf value (%s) which is also used for MinHeapFreeRatio must be less than or equal to MaxHeapFreeRatio (%3.2lf)\n",

Suggestion:

                      "-Xminf value (%s) must be less than or equal to the implicit -Xmaxf value (%3.2lf)\n",

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

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3172075416
PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2312872055
PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2312872585

From dholmes at openjdk.org  Mon Sep  1 04:49:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 04:49:43 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream
In-Reply-To: <1hCde5ZeDseE4OEegRk6GmcL7IbAlKIlW58WLdch4qg=.69de11c1-6116-4bb6-9efd-7039b69ad93e@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <1hCde5ZeDseE4OEegRk6GmcL7IbAlKIlW58WLdch4qg=.69de11c1-6116-4bb6-9efd-7039b69ad93e@github.com>
Message-ID: <geYB7oAS3lQ7iGDLEfXKUoHK9UWkjYuQ_RYOgKl309U=.be82e9ca-8fbe-41b3-b8bf-a0dccbdaa8cc@github.com>

On Sun, 24 Aug 2025 12:57:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> src/hotspot/share/classfile/javaClasses.cpp line 2621:
> 
>> 2619:   if (module_name != nullptr) {
>> 2620:     if (module_version != nullptr) {
>> 2621:       ss.print("%s@%s/", module_name, module_version);
> 
> Here and other places, this change is going to merge-conflict with https://github.com/openjdk/jdk/pull/26849.
> I think that PR should be allowed to go first.

That PR is now integrated. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2312876206

From dholmes at openjdk.org  Mon Sep  1 04:52:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 04:52:42 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v2]
In-Reply-To: <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
Message-ID: <cAWqI7PJsfz1OiliHy3UdBaZZ4tUVfSqlufK-hUSnow=.35b7b986-6d22-48bb-b3a3-873b3378757c@github.com>

On Fri, 29 Aug 2025 08:53:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vm.cds.nocoops.archive.available

This seems reasonable to me. One nit below.

I will run through our testing. Thanks

test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 98:

> 96: 
> 97:     private static boolean isArchiveAvailable(char coops, char coh,
> 98:                                                  String archiveSuffix) throws Exception {

Suggestion:

    private static boolean isArchiveAvailable(char coops, char coh,
                                              String archiveSuffix) throws Exception {

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

PR Review: https://git.openjdk.org/jdk/pull/26820#pullrequestreview-3172082364
PR Review Comment: https://git.openjdk.org/jdk/pull/26820#discussion_r2312877745

From dholmes at openjdk.org  Mon Sep  1 05:01:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 05:01:48 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v6]
In-Reply-To: <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>
Message-ID: <1vUQP7XEJkVUDX1ybjNYfk7a7fjiA2MaudLm5oOhv9g=.469db365-2d99-430c-936a-99b462a3bbfb@github.com>

On Fri, 29 Aug 2025 08:50:05 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364816: Addressed reviewer's comment.

LGTM! Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3172094430

From iklam at openjdk.org  Mon Sep  1 05:25:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 05:25:17 GMT
Subject: RFR: 8366498: Wrong InstanceKlass::cast() in
 ClassFileParser::parse_super_class
Message-ID: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>

Please review this small change. 

It affects debug build only, and I am not even sure if `cp->resolved_klass_at()` is ever called. Since we are very early in class file parsing, it's unlikely that any klass entries have been resolved at this point.

Anyway, for correctness, the `InstanceKlass::cast()` should be done after the check for array class.

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

Commit messages:
 - 8366498: Wrong InstanceKlass::cast() in ClassFileParser::parse_super_class

Changes: https://git.openjdk.org/jdk/pull/27026/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27026&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366498
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27026/head:pull/27026

PR: https://git.openjdk.org/jdk/pull/27026

From dholmes at openjdk.org  Mon Sep  1 06:29:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 06:29:41 GMT
Subject: RFR: 8366498: Wrong InstanceKlass::cast() in
 ClassFileParser::parse_super_class
In-Reply-To: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
Message-ID: <7t0HZFC1gbSzASP2899-2gcCNcUS_uF2uSbKzsYCPr8=.7391dd7a-999d-462a-a49a-6053881d0f52@github.com>

On Mon, 1 Sep 2025 05:19:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small change. 
> 
> It affects debug build only, and I am not even sure if `cp->resolved_klass_at()` is ever called. Since we are very early in class file parsing, it's unlikely that any klass entries have been resolved at this point.
> 
> Anyway, for correctness, the `InstanceKlass::cast()` should be done after the check for array class.

This does correct the cast but as you suggest this code should actually be unreachable - `is_klass()` will fail as no classes have been resolved at this stage of classfile parsing,

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

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3172246976

From dholmes at openjdk.org  Mon Sep  1 06:42:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 06:42:42 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v2]
In-Reply-To: <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
Message-ID: <sP2i7ZwcFTrjeP2dZNYeZChnp0yb19h3pLYy73N-u44=.148c7533-8020-436a-8d2c-14c7cc191322@github.com>

On Fri, 29 Aug 2025 08:53:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vm.cds.nocoops.archive.available

Testing passed.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26820#pullrequestreview-3172273130

From dholmes at openjdk.org  Mon Sep  1 06:52:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 06:52:45 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <nhEgDO9lqtKR7StyWO8qNFw3ZWsOg1RT9FuLWKC_bTY=.0de36e92-74c1-413c-9e15-507afc3872c3@github.com>

On Fri, 29 Aug 2025 07:58:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

Is there any reason this test should not work with other archives?

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

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3172298810

From dholmes at openjdk.org  Mon Sep  1 06:52:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 06:52:46 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <iNi92sOkar5HvRH1lYT5oj-1snavDLY0AwV4kdSF4T8=.b4e62b6d-b540-4bd5-ab0d-e946a3224088@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <iNi92sOkar5HvRH1lYT5oj-1snavDLY0AwV4kdSF4T8=.b4e62b6d-b540-4bd5-ab0d-e946a3224088@github.com>
Message-ID: <gX7h4iad2NZDQfPuwdv1NqZhGSa6J_MtoxfLNEbanhU=.6c124740-a801-4861-b439-a4445cd8eca1@github.com>

On Fri, 29 Aug 2025 18:06:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> LGTM (test fixs require only one reviewer)

@iklam  That is not stipulated in our dev guide. For hotspot changes only trivial changes revert to the single-reviewer rule.

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

PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3241064588

From mbaesken at openjdk.org  Mon Sep  1 06:59:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:59:22 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v3]
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <Uh-rybkm395QD1ilTXj2-uDNkNnC8t8N-WOpWfX4sAc=.a0174235-fcf5-49eb-a491-2b64cc016d18@github.com>

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26820/files
  - new: https://git.openjdk.org/jdk/pull/26820/files/567b8148..ac505301

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26820&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26820&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26820/head:pull/26820

PR: https://git.openjdk.org/jdk/pull/26820

From mbaesken at openjdk.org  Mon Sep  1 06:59:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:59:23 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v2]
In-Reply-To: <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <Xuzh1fL3NTf7-vzskqt6Ydo3YctSBgUfRpeuVmLX68c=.16e09f2e-d0cb-44f1-bf83-447919b37e86@github.com>
Message-ID: <X-p11BRHthsNJF_j8X7p3i8sEw01nOEyEEqKJHklgLs=.cf957c8e-968e-46fe-88a1-af63c6df347c@github.com>

On Fri, 29 Aug 2025 08:53:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vm.cds.nocoops.archive.available

I committed your suggestion - guess I need one re-review now ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26820#issuecomment-3241079894

From dholmes at openjdk.org  Mon Sep  1 07:05:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:05:44 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
Message-ID: <b2b3n1I9fdWH6Yfp_OQ5lw60mh9NaH66BENLsnfuY4I=.88a7633c-f393-48db-ae96-655b50678b19@github.com>

On Sun, 31 Aug 2025 03:48:18 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> ShowRegistersOnAssertTest.java verifies that registers are printed in the error log when VMError::controlled_crash() is called. However, it searches for the pattern "R0=", which is valid on Linux AArch64 only. The Windows AArch64 [os::print_context](https://github.com/openjdk/jdk/blob/999761d0f6d37c9cd6ec482620800b694c5fb9ad/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L184-L186) implementation outputs registers in the format "X0 =". This change updates the test to use this pattern on the Windows AArch64 platform. The test passes with this change.

Seems okay.

I have to ask though: why are the registers labelled X instead of R?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27022#pullrequestreview-3172328000

From iklam at openjdk.org  Mon Sep  1 07:14:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:14:28 GMT
Subject: RFR: 8366498: Wrong InstanceKlass::cast() in
 ClassFileParser::parse_super_class [v2]
In-Reply-To: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
Message-ID: <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>

> Please review this small change. 
> 
> It affects debug build only, and I am not even sure if `cp->resolved_klass_at()` is ever called. Since we are very early in class file parsing, it's unlikely that any klass entries have been resolved at this point.
> 
> Anyway, for correctness, the `InstanceKlass::cast()` should be done after the check for array class.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Simplify parse_super_klass() -> check_super_class()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27026/files
  - new: https://git.openjdk.org/jdk/pull/27026/files/d353bfe5..dec4af73

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

  Stats: 36 lines in 2 files changed: 8 ins; 10 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/27026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27026/head:pull/27026

PR: https://git.openjdk.org/jdk/pull/27026

From iklam at openjdk.org  Mon Sep  1 07:16:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:16:42 GMT
Subject: RFR: 8366498: Wrong InstanceKlass::cast() in
 ClassFileParser::parse_super_class [v2]
In-Reply-To: <7t0HZFC1gbSzASP2899-2gcCNcUS_uF2uSbKzsYCPr8=.7391dd7a-999d-462a-a49a-6053881d0f52@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <7t0HZFC1gbSzASP2899-2gcCNcUS_uF2uSbKzsYCPr8=.7391dd7a-999d-462a-a49a-6053881d0f52@github.com>
Message-ID: <Nd5Boe3f_b-DvTKWRBhr-5Xn_2-1urmo3CMRYHnRdwE=.3f68907e-508c-4752-8d73-2f12ef6ac932@github.com>

On Mon, 1 Sep 2025 06:27:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This does correct the cast but as you suggest this code should actually be unreachable - `is_klass()` will fail as no classes have been resolved at this stage of classfile parsing,

I removed the code for checking `is_klass()`. I added an assert() and it doesn't get hit at all in local testing. For curiosity, I will run it through the JCK and to see if we ever come here with a resolved class. I will remove the assert in the final version.

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

PR Comment: https://git.openjdk.org/jdk/pull/27026#issuecomment-3241131958

From iklam at openjdk.org  Mon Sep  1 07:21:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:21:41 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <nhEgDO9lqtKR7StyWO8qNFw3ZWsOg1RT9FuLWKC_bTY=.0de36e92-74c1-413c-9e15-507afc3872c3@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <nhEgDO9lqtKR7StyWO8qNFw3ZWsOg1RT9FuLWKC_bTY=.0de36e92-74c1-413c-9e15-507afc3872c3@github.com>
Message-ID: <UJ1eAMuG3w4I8M6P0-hTjanf_mhSj8U3qVFdk4eGyTc=.56443061-fafc-4de5-9c82-c6e9818b4df5@github.com>

On Mon, 1 Sep 2025 06:50:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Is there any reason this test should not work with other archives?

Please see my comment in https://bugs.openjdk.org/browse/JDK-8362566?focusedId=14812437&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14812437

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

PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3241148673

From dholmes at openjdk.org  Mon Sep  1 07:28:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:28:53 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v3]
In-Reply-To: <keVt1QMP_tId9Z70064-zFvb4Y9lmnqxNgMUp0wM3DY=.addc913d-c694-4efa-9da5-bf5e1b67ab88@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <keVt1QMP_tId9Z70064-zFvb4Y9lmnqxNgMUp0wM3DY=.addc913d-c694-4efa-9da5-bf5e1b67ab88@github.com>
Message-ID: <PWG6_RIRj3h1nErkwy5tS_werNTnyVBha9LUjwFVeSQ=.d07d4cc0-eee9-4e06-bba0-2e723ccc932a@github.com>

On Tue, 26 Aug 2025 07:55:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
>> 
>> When disabled, the test does not hang with ZGC enabled. 
>> 
>> Tested locally.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361370: Fixed typos in the comment.
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26895#pullrequestreview-3172399566

From duke at openjdk.org  Mon Sep  1 07:28:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 1 Sep 2025 07:28:54 GMT
Subject: RFR: 8361370: runtime/Thread/TestThreadDumpMonitorContention.java
 fails due to time out on Windows [v3]
In-Reply-To: <keVt1QMP_tId9Z70064-zFvb4Y9lmnqxNgMUp0wM3DY=.addc913d-c694-4efa-9da5-bf5e1b67ab88@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
 <keVt1QMP_tId9Z70064-zFvb4Y9lmnqxNgMUp0wM3DY=.addc913d-c694-4efa-9da5-bf5e1b67ab88@github.com>
Message-ID: <Ql0kQZPxySQZCPQtPqt2ki11Qiutu0zTsDcjn1bam38=.52ccfde8-e736-4081-a757-1898c5ba68d5@github.com>

On Tue, 26 Aug 2025 07:55:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
>> 
>> When disabled, the test does not hang with ZGC enabled. 
>> 
>> Tested locally.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361370: Fixed typos in the comment.
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

@toxaart 
Your change (at version 895a5d97376fd57f52a4de1ee288a38142c780d6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26895#issuecomment-3241169194

From dholmes at openjdk.org  Mon Sep  1 07:32:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:32:43 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
Message-ID: <EZXSyEdKkVbsFCSmhOVYDw-cNM8lkaU3FhXzGTeJOzU=.d623ac4c-5ac7-4703-9fb3-1b3c4831217c@github.com>

On Mon, 1 Sep 2025 07:14:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify parse_super_klass() -> check_super_class()

src/hotspot/share/classfile/classFileParser.cpp line 3824:

> 3822: 
> 3823:     // Ioi note: remove this in final commit.
> 3824:     assert(!cp->tag_at(super_class_index).is_klass(), "should not have been resolved");

I suggest not including this in the PR then adding it locally for testing purposes - else you guarantee the need for a re-review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313118181

From dholmes at openjdk.org  Mon Sep  1 07:42:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:42:47 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
Message-ID: <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>

On Mon, 1 Sep 2025 07:14:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify parse_super_klass() -> check_super_class()

Amazing how one incorrect cast led to that cascade of code changes. :)

Overall seems valid. A couple of nits.

Thanks

src/hotspot/share/classfile/classFileParser.cpp line 5798:

> 5796:   } else {
> 5797:     assert(_class_name == vmSymbols::java_lang_Object(), "already checked");
> 5798:     _super_klass = nullptr;

This seems unnecessary. We have already check the name and `_super_klass` is initialized to null.

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

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3172463258
PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313139011

From iklam at openjdk.org  Mon Sep  1 07:44:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:44:41 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <zqNZf5Wx6KwWgoY2_BIbI2WV85JbWsnsk_k_wDoG4Ps=.7d4fc1cc-334e-496f-a866-8d634366c221@github.com>

On Fri, 29 Aug 2025 07:58:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

Actually, I think it's better to remove the logic of explicitly setting `-XX:[+-]UseCompressedOops` in this test case. I.e., remove the `compressed` parameter to the `AOTMapTest.doTest()` function.

Instead, we should rely on tier testing for VM flag rotation. For example, in our CI, we have one test task that runs all tests with  `-vmoptions:-XX:-UseCompressedOops`.

----

With the current fix, I think the test will fail if you run it with  `-vmoptions:-XX:-UseCompressedOops` using your JDK:

- `vm.cds.default.archive.available` will report false (because your JDK doesn't have a classes_nocoops.jsa file)
- CDSAppTester will generate a temp-base JSA file to run the first scenario (-UseCompressedOops). This scenario will pass.
- CDSAppTester will then use the same temp-base JSA file to run the second scenario (+UseCompressedOops). This scenario will fail.
- `-vmoptions:-XX:-UseCompressedOops`

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3172470614

From iklam at openjdk.org  Mon Sep  1 07:49:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:49:42 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
Message-ID: <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>

On Mon, 1 Sep 2025 07:39:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify parse_super_klass() -> check_super_class()
>
> src/hotspot/share/classfile/classFileParser.cpp line 5798:
> 
>> 5796:   } else {
>> 5797:     assert(_class_name == vmSymbols::java_lang_Object(), "already checked");
>> 5798:     _super_klass = nullptr;
> 
> This seems unnecessary. We have already check the name and `_super_klass` is initialized to null.

I think it help people who wonder why `_super_klass` is not updated in this case. Maybe I can change the assignment to


asssert(_super_klass == nullptr, "already initialized");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313157080

From dholmes at openjdk.org  Mon Sep  1 07:53:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:53:48 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v3]
In-Reply-To: <Uh-rybkm395QD1ilTXj2-uDNkNnC8t8N-WOpWfX4sAc=.a0174235-fcf5-49eb-a491-2b64cc016d18@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <Uh-rybkm395QD1ilTXj2-uDNkNnC8t8N-WOpWfX4sAc=.a0174235-fcf5-49eb-a491-2b64cc016d18@github.com>
Message-ID: <kjiY4hXR9tIEiOjyTQgfs8hEnW57m2Wli8iCdK9nAU8=.1dcc4e82-3d62-4fdc-904e-eb3fffde5607@github.com>

On Mon, 1 Sep 2025 06:59:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26820#pullrequestreview-3172505174

From duke at openjdk.org  Mon Sep  1 07:53:56 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 1 Sep 2025 07:53:56 GMT
Subject: Integrated: 8361370:
 runtime/Thread/TestThreadDumpMonitorContention.java fails due to time out on
 Windows
In-Reply-To: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
References: <BZscaovi-OCDqFducnsfhzKJxLN-nh0nz1hlYEvEXTM=.c7e3342f-b587-46a3-a703-8b5773fd623a@github.com>
Message-ID: <8z5oPx2s0YoJ-_GHgb3sZsYzKHLqRibt051v4vVbSHY=.afe228d5-f267-4971-ad56-59c5853e1128@github.com>

On Fri, 22 Aug 2025 08:54:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> Jstack streaming output should be disabled in the test as JDK-8354461 suggest. 
> 
> When disabled, the test does not hang with ZGC enabled. 
> 
> Tested locally.

This pull request has now been integrated.

Changeset: 48f70d7a
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48f70d7ad85dde49cc8134d4ac0312978a5cc9f7
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8361370: runtime/Thread/TestThreadDumpMonitorContention.java fails due to time out on Windows

Reviewed-by: dholmes, amenkov

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

PR: https://git.openjdk.org/jdk/pull/26895

From iklam at openjdk.org  Mon Sep  1 07:55:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:55:39 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v3]
In-Reply-To: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
Message-ID: <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>

> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  removed test-only assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27026/files
  - new: https://git.openjdk.org/jdk/pull/27026/files/dec4af73..256716fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27026&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27026&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27026/head:pull/27026

PR: https://git.openjdk.org/jdk/pull/27026

From iklam at openjdk.org  Mon Sep  1 07:55:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 07:55:42 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <EZXSyEdKkVbsFCSmhOVYDw-cNM8lkaU3FhXzGTeJOzU=.d623ac4c-5ac7-4703-9fb3-1b3c4831217c@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <EZXSyEdKkVbsFCSmhOVYDw-cNM8lkaU3FhXzGTeJOzU=.d623ac4c-5ac7-4703-9fb3-1b3c4831217c@github.com>
Message-ID: <hwx8ur-WARqOGelPAaQDhTqXzVZhra9OcrkubmuY6QE=.09d8ffc3-25c4-4066-b3a8-4b6bb9584ce5@github.com>

On Mon, 1 Sep 2025 07:29:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify parse_super_klass() -> check_super_class()
>
> src/hotspot/share/classfile/classFileParser.cpp line 3824:
> 
>> 3822: 
>> 3823:     // Ioi note: remove this in final commit.
>> 3824:     assert(!cp->tag_at(super_class_index).is_klass(), "should not have been resolved");
> 
> I suggest not including this in the PR then adding it locally for testing purposes - else you guarantee the need for a re-review.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313167151

From azafari at openjdk.org  Mon Sep  1 07:57:32 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 1 Sep 2025 07:57:32 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v5]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <dWTJCoiO7zoqQkigFaIpcatgpvh2RS0YKhc1GIMbRu8=.631bd401-4853-4239-9b29-c9eb9ad2535f@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  better messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/7f18f689..5854ef36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26859/head:pull/26859

PR: https://git.openjdk.org/jdk/pull/26859

From dholmes at openjdk.org  Mon Sep  1 07:57:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 07:57:42 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
 <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>
Message-ID: <wUuHNQ-Eq5davnomMuo-H_YGZXVfyj-DTInMXUD_wNw=.418016f0-2655-4243-bd2e-dad31d4d9dd8@github.com>

On Mon, 1 Sep 2025 07:47:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 5798:
>> 
>>> 5796:   } else {
>>> 5797:     assert(_class_name == vmSymbols::java_lang_Object(), "already checked");
>>> 5798:     _super_klass = nullptr;
>> 
>> This seems unnecessary. We have already check the name and `_super_klass` is initialized to null.
>
> I think it help people who wonder why `_super_klass` is not updated in this case. Maybe I can change the assignment to
> 
> 
> asssert(_super_klass == nullptr, "already initialized");

I would just have:

else {
  // The class is Object - so no superclass
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313174940

From azafari at openjdk.org  Mon Sep  1 07:57:32 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 1 Sep 2025 07:57:32 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v4]
In-Reply-To: <jnsthDEUCyCPMAdTdOiIKQjUKsdZ_1K5oJUPGD2gKOk=.e046d6fb-7251-4e1d-9854-01569d440200@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <KlKYfOCdt3BRQzlumgqblAec2VV9oJnt9bZ_ca8Nb_c=.bde9b177-a8ac-4043-b363-3225b89a7674@github.com>
 <jnsthDEUCyCPMAdTdOiIKQjUKsdZ_1K5oJUPGD2gKOk=.e046d6fb-7251-4e1d-9854-01569d440200@github.com>
Message-ID: <eqY5MVauK17MvEAIaohSDjpgeFdTzYKkSlFeL46qymA=.24274bf9-babf-476a-aead-0e16909d8273@github.com>

On Mon, 1 Sep 2025 04:42:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved tests and messages.
>
> src/hotspot/share/runtime/arguments.cpp line 2429:
> 
>> 2427:         if (MinHeapFreeRatio > (uintx)(dmaxf * 100)) {
>> 2428:           jio_fprintf(defaultStream::error_stream(),
>> 2429:                       "-Xmaxf value (%s) which is also used for MaxHeapFreeRatio must be greater than or equal to MinHeapFreeRatio (%3.2lf)\n",
> 
> Suggestion:
> 
>                       "-Xmaxf value (%s) must be greater than or equal to the implicit -Xminf value (%3.2lf)\n",

Done.

> src/hotspot/share/runtime/arguments.cpp line 2455:
> 
>> 2453:         if (MaxHeapFreeRatio < (uintx)(dminf * 100)) {
>> 2454:           jio_fprintf(defaultStream::error_stream(),
>> 2455:                       "-Xminf value (%s) which is also used for MinHeapFreeRatio must be less than or equal to MaxHeapFreeRatio (%3.2lf)\n",
> 
> Suggestion:
> 
>                       "-Xminf value (%s) must be less than or equal to the implicit -Xmaxf value (%3.2lf)\n",

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2313171608
PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2313172090

From iklam at openjdk.org  Mon Sep  1 08:03:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 08:03:41 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <wUuHNQ-Eq5davnomMuo-H_YGZXVfyj-DTInMXUD_wNw=.418016f0-2655-4243-bd2e-dad31d4d9dd8@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
 <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>
 <wUuHNQ-Eq5davnomMuo-H_YGZXVfyj-DTInMXUD_wNw=.418016f0-2655-4243-bd2e-dad31d4d9dd8@github.com>
Message-ID: <LqtMMBDoD9LlxZzSINgKLF6ylVjMYUlS9_MptG0sE2k=.1172df57-4f9f-4f92-aa36-42f2a0e1159b@github.com>

On Mon, 1 Sep 2025 07:54:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it help people who wonder why `_super_klass` is not updated in this case. Maybe I can change the assignment to
>> 
>> 
>> asssert(_super_klass == nullptr, "already initialized");
>
> I would just have:
> 
> else {
>   // The class is Object - so no superclass
> }

My asserts say the same thing, except they comes with proofs that they are not lying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2313189601

From mbaesken at openjdk.org  Mon Sep  1 08:07:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 08:07:01 GMT
Subject: RFR: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives [v3]
In-Reply-To: <Uh-rybkm395QD1ilTXj2-uDNkNnC8t8N-WOpWfX4sAc=.a0174235-fcf5-49eb-a491-2b64cc016d18@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
 <Uh-rybkm395QD1ilTXj2-uDNkNnC8t8N-WOpWfX4sAc=.a0174235-fcf5-49eb-a491-2b64cc016d18@github.com>
Message-ID: <v_2XgUPW0-BplE9mL7Lyq1D0ilnCHkFLc71fTnBDmA8=.087c6872-643f-41fc-ba07-a9a5b07edf81@github.com>

On Mon, 1 Sep 2025 06:59:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
>> But not all tests can deal with this.
>> Namely
>> 
>> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
>> 
>> were found to have issues.
>> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26820#issuecomment-3241292622

From mbaesken at openjdk.org  Mon Sep  1 08:07:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 08:07:02 GMT
Subject: Integrated: 8364352: Some tests fail when using a limited number of
 pregenerated .jsa CDS archives
In-Reply-To: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
References: <EnyzXiapmd29T3spHQT7QTBv2SVQVKVU6L2NEDoejHg=.65f803f7-09e0-4e5b-ac21-a60474c5facd@github.com>
Message-ID: <37a7ACDL1rRzsPfeg4Y-6wXF6E7-S81YlQyovOC4Mhc=.1938c8ea-2bb0-482a-8144-da24025dc94f@github.com>

On Mon, 18 Aug 2025 11:34:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the default JVM comes on most platforms with 4 jsa files (for coops and nocoops; with and without compressed object headers), but for some shipments the number of jsa could be reduced (see also Images.gmk) .
> But not all tests can deal with this.
> Namely
> 
> test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java (custom-cl-zgc)
> 
> were found to have issues.
> There is already a requires  `vm.cds.default.archive.available`   that is used in similar tests and can be used in some of those cases too.

This pull request has now been integrated.

Changeset: 3ca44c8d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ca44c8dea035588070644e5c1f8f25559f66e53
Stats:     27 lines in 5 files changed: 22 ins; 0 del; 5 mod

8364352: Some tests fail when using a limited number of pregenerated .jsa CDS archives

Reviewed-by: dholmes, stuefe

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

PR: https://git.openjdk.org/jdk/pull/26820

From jsjolen at openjdk.org  Mon Sep  1 09:16:43 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 1 Sep 2025 09:16:43 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
Message-ID: <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>

On Thu, 28 Aug 2025 11:21:00 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current red-black tree can be made safer, and its inspection capabilities improved.
>> 
>> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
>> 
>> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
>> 
>> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
>> 
>> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
>> 
>> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   albert feedback

src/hotspot/share/utilities/rbTree.hpp line 65:

> 63: // Nodes are address stable and will not change during its lifetime.
> 64: 
> 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 };

Is assigning the elements to specific values necessary?

src/hotspot/share/utilities/rbTree.hpp line 133:

> 131:               size_t& tree_depth, bool expect_visited, NodeVerifier verifier,
> 132:               const USER_VERIFIER& extra_verifier) const;
> 133: 

`NodeType` is unused. Here we have two different naming standards for the template name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313349689
PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313358762

From jsjolen at openjdk.org  Mon Sep  1 09:16:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 1 Sep 2025 09:16:44 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
 <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>
Message-ID: <vYH5lFXbLLVTcQm1yvIVCmhER8bWxgn561j8wmO1Gww=.bad732c5-8e78-4d39-b02b-a905147c91a0@github.com>

On Mon, 1 Sep 2025 09:04:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   albert feedback
>
> src/hotspot/share/utilities/rbTree.hpp line 65:
> 
>> 63: // Nodes are address stable and will not change during its lifetime.
>> 64: 
>> 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 };
> 
> Is assigning the elements to specific values necessary?

Personally, I'd prefer LT, EQ, GT to be the enum members. I'd like to see a `TotalOrdering` enum class in the future, to replace this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313370588

From shade at openjdk.org  Mon Sep  1 09:42:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Sep 2025 09:42:41 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
Message-ID: <Npz-COo2rYB2tlXt_qNtk_Eweb4070semqq0eMsf8KU=.19563e63-ad9a-4b78-ba4a-7b43f34090a3@github.com>

On Sun, 31 Aug 2025 03:48:18 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> ShowRegistersOnAssertTest.java verifies that registers are printed in the error log when VMError::controlled_crash() is called. However, it searches for the pattern "R0=", which is valid on Linux AArch64 only. The Windows AArch64 [os::print_context](https://github.com/openjdk/jdk/blob/999761d0f6d37c9cd6ec482620800b694c5fb9ad/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L184-L186) implementation outputs registers in the format "X0 =". This change updates the test to use this pattern on the Windows AArch64 platform. The test passes with this change.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27022#pullrequestreview-3172917197

From shade at openjdk.org  Mon Sep  1 09:42:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Sep 2025 09:42:42 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <b2b3n1I9fdWH6Yfp_OQ5lw60mh9NaH66BENLsnfuY4I=.88a7633c-f393-48db-ae96-655b50678b19@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
 <b2b3n1I9fdWH6Yfp_OQ5lw60mh9NaH66BENLsnfuY4I=.88a7633c-f393-48db-ae96-655b50678b19@github.com>
Message-ID: <iPcxYGcnd9D7sCWITCiAu0RC_HDAFNm5Do-ytZdBoIU=.99c40d31-e061-4ac1-8f55-b3339f30d09b@github.com>

On Mon, 1 Sep 2025 07:02:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I have to ask though: why are the registers labelled X instead of R?

`X` is the common name for 64-bit register in AArch64 ISA, I think that's why. The external `CONTEXT` also labels them `X*`: https://github.com/openjdk/jdk/blob/98af18921aa3c274ef7ece03005337b58df3da96/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L186

And:
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-arm64_nt_context

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

PR Comment: https://git.openjdk.org/jdk/pull/27022#issuecomment-3241635412

From duke at openjdk.org  Mon Sep  1 09:51:30 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 1 Sep 2025 09:51:30 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v7]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/os/windows/os_windows.cpp
  
  8364816: Added _set_errno(0) to avoid reading old values.
  
  Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/e920baff..2789bb92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=05-06

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From jsikstro at openjdk.org  Mon Sep  1 09:51:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Sep 2025 09:51:31 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v6]
In-Reply-To: <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>
Message-ID: <yXQx8_N1Fe84K0d6yb7qn_LkXHY-MKWeZYfEWVb0kYU=.fe9e1189-67fa-4605-b447-0c5f5a0aa6c0@github.com>

On Fri, 29 Aug 2025 08:50:05 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364816: Addressed reviewer's comment.

src/hotspot/os/windows/os_windows.cpp line 4822:

> 4820:     if (errcode == ERROR_FILE_NOT_FOUND || errcode == ERROR_PATH_NOT_FOUND) {
> 4821:       errno = ENOENT;
> 4822:     }

To maintain the old behavior, we should set errno to 0 to avoid reading an old value of a previous error stored in errno, which could change the behavior or either succeeding or crashing in aotClassLocation.cpp.

Suggestion:

    } else {
      _set_errno(0);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2313451830

From duke at openjdk.org  Mon Sep  1 09:51:31 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 1 Sep 2025 09:51:31 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v6]
In-Reply-To: <yXQx8_N1Fe84K0d6yb7qn_LkXHY-MKWeZYfEWVb0kYU=.fe9e1189-67fa-4605-b447-0c5f5a0aa6c0@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <l0Sb8ystdCPoDocOKaVfD9UOcQGyhzEmPgv1DrIHYd8=.03b1a1d3-afda-4f29-89e5-9c5966cf17d9@github.com>
 <yXQx8_N1Fe84K0d6yb7qn_LkXHY-MKWeZYfEWVb0kYU=.fe9e1189-67fa-4605-b447-0c5f5a0aa6c0@github.com>
Message-ID: <1jehFPxaWTlVymG79rvv0VD7YZ5WhchLi4Mqw2JjS7s=.83ff45f7-0cea-4e6b-a380-8969ba1b4176@github.com>

On Mon, 1 Sep 2025 09:45:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364816: Addressed reviewer's comment.
>
> src/hotspot/os/windows/os_windows.cpp line 4822:
> 
>> 4820:     if (errcode == ERROR_FILE_NOT_FOUND || errcode == ERROR_PATH_NOT_FOUND) {
>> 4821:       errno = ENOENT;
>> 4822:     }
> 
> To maintain the old behavior, we should set errno to 0 to avoid reading an old value of a previous error stored in errno, which could change the behavior or either succeeding or crashing in aotClassLocation.cpp.
> 
> Suggestion:
> 
>     } else {
>       _set_errno(0);
>     }

I think it is a good catch, let's add it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2313453433

From jsikstro at openjdk.org  Mon Sep  1 09:58:43 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 1 Sep 2025 09:58:43 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v7]
In-Reply-To: <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>
Message-ID: <4Z2NelPEOXRPRJRA1L2_5cZx7B7N_sYCTdY13BfbxcI=.ca638dda-be31-4de3-a4af-a6b0dabbb2e4@github.com>

On Mon, 1 Sep 2025 09:51:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os/windows/os_windows.cpp
>   
>   8364816: Added _set_errno(0) to avoid reading old values.
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Thank you for this, I think this is a step in the right direction.

I think this looks good now, since there is no change in external behavior of using `os::stat()`. I agree that setting errno to `GetLastError()` was broken, which is now fixed, nice! But reading errno after `os::stat()` is as broken before as it is now and should really be fixed in a follow-up. Users of `os::stat()` should only check if the call is successful or not, until we have a robust method in place for detecting specific errors.

It would have been nice to fix `os::stat()` before this, which would have meant we didn't have to consider the specific use-case in `aotClassLocation.cpp` which reads errno.

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

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3172971080

From mbaesken at openjdk.org  Mon Sep  1 10:17:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 10:17:42 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <zqNZf5Wx6KwWgoY2_BIbI2WV85JbWsnsk_k_wDoG4Ps=.7d4fc1cc-334e-496f-a866-8d634366c221@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <zqNZf5Wx6KwWgoY2_BIbI2WV85JbWsnsk_k_wDoG4Ps=.7d4fc1cc-334e-496f-a866-8d634366c221@github.com>
Message-ID: <yNydUBzypvaG_GjJr6SD90SfzYPLT8EiLaCL8m2RLYM=.bc0791db-2aa9-4e48-9635-cc4ea9a105d5@github.com>

On Mon, 1 Sep 2025 07:41:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> With the current fix, I think the test will fail if you run it with -vmoptions:-XX:-UseCompressedOops using your JDK

The test has `vm.flagless` set , so would it be skipped in this case ?

>  remove the compressed parameter to the AOTMapTest.doTest() function

okay why not ;  would compressed == true be the remaining default case then ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3241771449
PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3241774167

From egahlin at openjdk.org  Mon Sep  1 12:00:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 1 Sep 2025 12:00:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <ZHFJbzLE75LKyGr0KHJNWH8aSVKoM-8JEPw6EwFcijM=.2daca368-baa2-449c-9148-d6ce8ee2a0d3@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Does your change handle logging to a file?

I looked into fixing this when I did the initial implementation, but I didn't think it was worth addressing. It only applies to jfr+startup and if the user wants the warning level. If a user doesn't want the message, they can specify jfr+startup=error.

Do we log anything with jfr+startup=warning?

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242090448

From jbechberger at openjdk.org  Mon Sep  1 12:16:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 1 Sep 2025 12:16:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <BqiiVfOsqjbyhmhCwKsiQNobdVkyeRj3vAL12iQNUW0=.098eaab2-c9f8-4cf6-b304-1f9a2049ba1e@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Without this change, `jfr+startup=warning` doesn't affect the startup logging at all, and it shows the startup message, which was confusing to one of our users (why is it showing `[info]` tagged startup messages when the warning level is set).

I'll look into how it handles files later in the day

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242135188

From cnorrbin at openjdk.org  Mon Sep  1 12:27:43 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Sep 2025 12:27:43 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock
In-Reply-To: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com>
Message-ID: <mLXstQsC1gK5ytIY20swbJWy025hYZqqj8p6jXZd9HE=.cab7d2c1-1b8d-4cc6-8495-2b5472a2359b@github.com>

On Fri, 29 Aug 2025 19:02:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> src/hotspot/share/utilities/rbTree.hpp line 454:
> 
>> 452: public:
>> 453:   RBTree() : BaseType(), _allocator() {}
>> 454:   RBTree(const RBTree& other) : BaseType(), _allocator() {
> 
> @caspernorrbin , I added this. Does it look correct?

Looks correct to me, as long as the value type can also be properly copy-constructible. Maybe we can add in an assert to avoid potential future misuse? :-)

Something like:
`assert(std::is_copy_constructible<V>(), "Value type must be copy-constructible");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2313812719

From jsjolen at openjdk.org  Mon Sep  1 13:15:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 1 Sep 2025 13:15:45 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock
In-Reply-To: <mLXstQsC1gK5ytIY20swbJWy025hYZqqj8p6jXZd9HE=.cab7d2c1-1b8d-4cc6-8495-2b5472a2359b@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com>
 <mLXstQsC1gK5ytIY20swbJWy025hYZqqj8p6jXZd9HE=.cab7d2c1-1b8d-4cc6-8495-2b5472a2359b@github.com>
Message-ID: <P3h0t0dkds_K5FSSMjvPrhFKqU1hs79OPsttBzt7C-I=.d1ad3b41-2135-4f4d-a182-ef0f6a898eec@github.com>

On Mon, 1 Sep 2025 12:25:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 454:
>> 
>>> 452: public:
>>> 453:   RBTree() : BaseType(), _allocator() {}
>>> 454:   RBTree(const RBTree& other) : BaseType(), _allocator() {
>> 
>> @caspernorrbin , I added this. Does it look correct?
>
> Looks correct to me, as long as the value type can also be properly copy-constructible. Maybe we can add in an assert to avoid potential future misuse? :-)
> 
> Something like:
> `assert(std::is_copy_constructible<V>(), "Value type must be copy-constructible");`

Yeah, we can do that! I'll put it in a static_assert even.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2313930488

From jsjolen at openjdk.org  Mon Sep  1 13:22:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 1 Sep 2025 13:22:03 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Static assert copy-constructible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/958c9706..a125e582

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From cnorrbin at openjdk.org  Mon Sep  1 13:40:28 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Sep 2025 13:40:28 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v4]
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <SYGF5A7yQYsBkplGSJTKxGGAivSkIANwAdt33MIzMvo=.9d5984b2-1eae-4fe3-a5d0-fb7d02d4984d@github.com>

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
> 
> Testing:
> - Oracle tiers 1-3

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  johan feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26981/files
  - new: https://git.openjdk.org/jdk/pull/26981/files/f780a53e..f7ce633b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=02-03

  Stats: 56 lines in 6 files changed: 8 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/26981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981

PR: https://git.openjdk.org/jdk/pull/26981

From cnorrbin at openjdk.org  Mon Sep  1 13:40:29 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Sep 2025 13:40:29 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <vYH5lFXbLLVTcQm1yvIVCmhER8bWxgn561j8wmO1Gww=.bad732c5-8e78-4d39-b02b-a905147c91a0@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
 <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>
 <vYH5lFXbLLVTcQm1yvIVCmhER8bWxgn561j8wmO1Gww=.bad732c5-8e78-4d39-b02b-a905147c91a0@github.com>
Message-ID: <0-Qp9OoEh4x_uB6YBWqTJJiDwcFVnY9xRlqKf2oIBNY=.2f9b5c13-d577-41e2-bf2d-090ca66f07cf@github.com>

On Mon, 1 Sep 2025 09:12:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 65:
>> 
>>> 63: // Nodes are address stable and will not change during its lifetime.
>>> 64: 
>>> 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 };
>> 
>> Is assigning the elements to specific values necessary?
>
> Personally, I'd prefer LT, EQ, GT to be the enum members. I'd like to see a `TotalOrdering` enum class in the future, to replace this.

I assigned the values so they'd be similar to the previous `int` return, not really needed.
I don't mind the other names, so renamed to LT, EQ, GT and removed the values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313986169

From cnorrbin at openjdk.org  Mon Sep  1 13:40:29 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 1 Sep 2025 13:40:29 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v3]
In-Reply-To: <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com>
 <h0psAJEypKfCYsy6GEp0l7N9LEEanekbJZ2uiF8e7_o=.87815df7-909e-4261-a80e-895f941cc8c6@github.com>
Message-ID: <1Rnx8JXn2FoHMMFGa04Nm9kqTNqZdYXJv-ZoOlYIrA8=.41f1a1f2-23cd-4eff-8565-3ffd7e82b2fd@github.com>

On Mon, 1 Sep 2025 09:08:00 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   albert feedback
>
> src/hotspot/share/utilities/rbTree.hpp line 133:
> 
>> 131:               size_t& tree_depth, bool expect_visited, NodeVerifier verifier,
>> 132:               const USER_VERIFIER& extra_verifier) const;
>> 133: 
> 
> `NodeType` is unused. Here we have two different naming standards for the template name.

`NodeType` is used in the inline file so is needed. Renamed `NodeVerifier` to `NODE_VERIFIER` to fit in with the other templates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313988884

From duke at openjdk.org  Mon Sep  1 14:02:40 2025
From: duke at openjdk.org (duke)
Date: Mon, 1 Sep 2025 14:02:40 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
Message-ID: <55TAeoF1PKiVH0msTBtkJ_yWaaGgnIDSls2CzpwoyD8=.7cabc1ca-a52f-497f-9820-7f71c9b8ca66@github.com>

On Sun, 31 Aug 2025 03:48:18 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> ShowRegistersOnAssertTest.java verifies that registers are printed in the error log when VMError::controlled_crash() is called. However, it searches for the pattern "R0=", which is valid on Linux AArch64 only. The Windows AArch64 [os::print_context](https://github.com/openjdk/jdk/blob/999761d0f6d37c9cd6ec482620800b694c5fb9ad/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L184-L186) implementation outputs registers in the format "X0 =". This change updates the test to use this pattern on the Windows AArch64 platform. The test passes with this change.

@swesonga 
Your change (at version 0cdc319a9095f962232d5db835e3bf6f8f679130) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27022#issuecomment-3242490994

From iklam at openjdk.org  Mon Sep  1 17:20:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 1 Sep 2025 17:20:41 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing
In-Reply-To: <yNydUBzypvaG_GjJr6SD90SfzYPLT8EiLaCL8m2RLYM=.bc0791db-2aa9-4e48-9635-cc4ea9a105d5@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <zqNZf5Wx6KwWgoY2_BIbI2WV85JbWsnsk_k_wDoG4Ps=.7d4fc1cc-334e-496f-a866-8d634366c221@github.com>
 <yNydUBzypvaG_GjJr6SD90SfzYPLT8EiLaCL8m2RLYM=.bc0791db-2aa9-4e48-9635-cc4ea9a105d5@github.com>
Message-ID: <fyCUPFo4tyelnjMmY4by7_BRfgBi8xuFP3fGPHk69Jw=.2ad948ea-0c01-4dff-a267-e8916fb51b52@github.com>

On Mon, 1 Sep 2025 10:14:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > With the current fix, I think the test will fail if you run it with -vmoptions:-XX:-UseCompressedOops using your JDK
> 
> The test has `vm.flagless` set , so would it be skipped in this case ?

I think `vm.flagless` should also be removed. The contents of the AOT cache will be different depending on certain VM flags (e.g., GC flags), so running this test with flag rotation may provide better coverage.

(The test test/hotspot/jtreg/runtime/cds/CDSMapTest.java didn't have  `vm.flagless` until recently (when I added AOTMapTest.java), so I think we should also remove `vm.flagless` from CDSMapTest.java as well.

> > remove the compressed parameter to the AOTMapTest.doTest() function
> 
> okay why not ; would compressed == true be the remaining default case then ?

We should remove all use of the `compressed` variable, including this code:


            if (Platform.is64bit()) {
                // These options are available only on 64-bit.
                String sign = (compressed) ?  "+" : "-";
                vmArgs.add("-XX:" + sign + "UseCompressedOops");
            }


And let `UseCompressedOops` be decided by VM default and jtreg `-vmoptions`. So yes, by default this test will (implicitly) run with compressed oops.

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

PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3242959524
PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3242962992

From dholmes at openjdk.org  Mon Sep  1 21:01:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 21:01:42 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v3]
In-Reply-To: <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
Message-ID: <ld9RbuDpG-YuVTl_x64hrIoUeVbu7BNWZ4c5wwyrZUc=.da4a5163-e300-406c-8afa-92aab6f3530c@github.com>

On Mon, 1 Sep 2025 07:55:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed test-only assert

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3174479526

From dholmes at openjdk.org  Mon Sep  1 21:32:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 21:32:43 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v5]
In-Reply-To: <dWTJCoiO7zoqQkigFaIpcatgpvh2RS0YKhc1GIMbRu8=.631bd401-4853-4239-9b29-c9eb9ad2535f@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <dWTJCoiO7zoqQkigFaIpcatgpvh2RS0YKhc1GIMbRu8=.631bd401-4853-4239-9b29-c9eb9ad2535f@github.com>
Message-ID: <qT3eJ3x1B8fatboQaMnkI6gPmyHuJgUYi5oRTKR3RRU=.7e14d6f5-6007-4ae6-b7aa-ae44db7cb99e@github.com>

On Mon, 1 Sep 2025 07:57:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better messages

Changes requested by dholmes (Reviewer).

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

> 2427:         if (MinHeapFreeRatio > (uintx)(dmaxf * 100)) {
> 2428:           jio_fprintf(defaultStream::error_stream(),
> 2429:                       "-Xmaxf value (%s) must be greater than or equal to the implicit -Xmaxf value (%3.2lf)\n",

Suggestion:

                      "-Xmaxf value (%s) must be greater than or equal to the implicit -Xminf value (%3.2lf)\n",

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

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3174502001
PR Review Comment: https://git.openjdk.org/jdk/pull/26859#discussion_r2314585180

From dholmes at openjdk.org  Mon Sep  1 21:37:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Sep 2025 21:37:44 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v7]
In-Reply-To: <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>
Message-ID: <bNwcuUbyoIVgyDcOCbd1AUstDlxERsLNLqJysMfywX0=.6b237132-a623-4d8d-8e11-7dc49bed34a1@github.com>

On Mon, 1 Sep 2025 09:51:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os/windows/os_windows.cpp
>   
>   8364816: Added _set_errno(0) to avoid reading old values.
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Changes requested by dholmes (Reviewer).

src/hotspot/os/windows/os_windows.cpp line 4823:

> 4821:       errno = ENOENT;
> 4822:     } else {
> 4823:       _set_errno(0);

I don't object to setting it to zero explicitly but we do not need to use `_set_errno` to do it!
Suggestion:

      errno = 0;

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

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3174505140
PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2314587851

From dholmes at openjdk.org  Tue Sep  2 04:03:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 04:03:47 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <iPcxYGcnd9D7sCWITCiAu0RC_HDAFNm5Do-ytZdBoIU=.99c40d31-e061-4ac1-8f55-b3339f30d09b@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
 <b2b3n1I9fdWH6Yfp_OQ5lw60mh9NaH66BENLsnfuY4I=.88a7633c-f393-48db-ae96-655b50678b19@github.com>
 <iPcxYGcnd9D7sCWITCiAu0RC_HDAFNm5Do-ytZdBoIU=.99c40d31-e061-4ac1-8f55-b3339f30d09b@github.com>
Message-ID: <teo3iW7a4TWDV0oW_2j78UsVPAOGE5196k6snEWitL0=.1e074d95-3d12-4799-a2a6-94e9bdff33ef@github.com>

On Mon, 1 Sep 2025 09:39:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I have to ask though: why are the registers labelled X instead of R?
> 
> `X` is the common name for 64-bit register in AArch64 ISA, I think that's why. The external `CONTEXT` also labels them `X*`:
> 
> https://github.com/openjdk/jdk/blob/98af18921aa3c274ef7ece03005337b58df3da96/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L186
> 
> And: https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-arm64_nt_context

But is that Windows specific? I'm wondering why Windows-Aarch64 uses X whereas Linux-aarch64 uses R.

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

PR Comment: https://git.openjdk.org/jdk/pull/27022#issuecomment-3243704804

From duke at openjdk.org  Tue Sep  2 04:03:48 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 2 Sep 2025 04:03:48 GMT
Subject: Integrated: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
Message-ID: <YLYXWzAdELSX0xMouqoutZf_mCKI6vY517W_2eTTuGc=.b6abce35-dd9b-42cc-8d98-88839c436862@github.com>

On Sun, 31 Aug 2025 03:48:18 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> ShowRegistersOnAssertTest.java verifies that registers are printed in the error log when VMError::controlled_crash() is called. However, it searches for the pattern "R0=", which is valid on Linux AArch64 only. The Windows AArch64 [os::print_context](https://github.com/openjdk/jdk/blob/999761d0f6d37c9cd6ec482620800b694c5fb9ad/src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp#L184-L186) implementation outputs registers in the format "X0 =". This change updates the test to use this pattern on the Windows AArch64 platform. The test passes with this change.

This pull request has now been integrated.

Changeset: f58d612b
Author:    Saint Wesonga <saint.wesonga at microsoft.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f58d612b6111658f01fa6b927bb2b2032c685620
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8366483: ShowRegistersOnAssertTest uses wrong register pattern string for Windows on AArch64

Reviewed-by: dholmes, shade

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

PR: https://git.openjdk.org/jdk/pull/27022

From jnordstrom at openjdk.org  Tue Sep  2 06:40:43 2025
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Tue, 2 Sep 2025 06:40:43 GMT
Subject: RFR: 8365913: Support latest MSC_VER in abstract_vm_version.cpp
In-Reply-To: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
References: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
Message-ID: <GfBFuLoVCYRkbOPEeQxx3v9MFIelO0yX7AUEo8ea21k=.e8ced94d-3570-46fb-9ccc-5a6f275c5317@github.com>

On Thu, 21 Aug 2025 09:59:14 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> With the latest devkit upgrade for Windows, hs_err files and `-Xinternalversion` reports "`unknown MS VC++:1943`".
> 
> This fix adds the latest known MSC_VER version, as of current date according to https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170.
> 
> ### Testing
> - [x] Built locally and verified MSVC version is reported correctly
> - [x] tier1-tier3

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/26878#issuecomment-3243983641

From duke at openjdk.org  Tue Sep  2 06:40:43 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Sep 2025 06:40:43 GMT
Subject: RFR: 8365913: Support latest MSC_VER in abstract_vm_version.cpp
In-Reply-To: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
References: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
Message-ID: <HG5LgZh-VY30hcJ8h6H_DOyoqwV-V3QxLe4Y5CUrW14=.c1944bc7-9634-4a3a-9014-a0e2c32428e0@github.com>

On Thu, 21 Aug 2025 09:59:14 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> With the latest devkit upgrade for Windows, hs_err files and `-Xinternalversion` reports "`unknown MS VC++:1943`".
> 
> This fix adds the latest known MSC_VER version, as of current date according to https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170.
> 
> ### Testing
> - [x] Built locally and verified MSVC version is reported correctly
> - [x] tier1-tier3

@jaokim 
Your change (at version e4a4ceb2065405f39b35e55591bb9fe163e5a076) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26878#issuecomment-3243986015

From jsjolen at openjdk.org  Tue Sep  2 07:03:27 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 07:03:27 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <AT-fAKCyc1z07jTOkqB5DmVY8yyyqWlJgsArRE71zFg=.5e2ecbfb-552e-4bb6-ab60-5545f3945311@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Add misisng locks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/a125e582..800eca26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=01-02

  Stats: 31 lines in 3 files changed: 16 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 07:07:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 07:07:41 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3]
In-Reply-To: <AT-fAKCyc1z07jTOkqB5DmVY8yyyqWlJgsArRE71zFg=.5e2ecbfb-552e-4bb6-ab60-5545f3945311@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <AT-fAKCyc1z07jTOkqB5DmVY8yyyqWlJgsArRE71zFg=.5e2ecbfb-552e-4bb6-ab60-5545f3945311@github.com>
Message-ID: <B9qZPY6o9u1XVJCe42HwUgh2Tdeyy5wAiv92-fEPNFk=.bc050ec5-7969-4300-9170-cebaa917c045@github.com>

On Tue, 2 Sep 2025 07:03:27 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

Oops, I accidentally committed to my current branch, I meant to commit to a new one. I'm going to rewrite history a bit, sorry bot.

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244054097

From duke at openjdk.org  Tue Sep  2 07:31:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 07:31:28 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v8]
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <bZUI7M0PUs80PYJIGvB3jztFXgcRfkMWSQWGLxVN8rY=.df91b9c6-84b8-4279-b642-5d28ea0195db@github.com>

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/os/windows/os_windows.cpp
  
  8364816: Changed the way errno is set to zero.
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26901/files
  - new: https://git.openjdk.org/jdk/pull/26901/files/2789bb92..9d69ac3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26901&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26901.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26901/head:pull/26901

PR: https://git.openjdk.org/jdk/pull/26901

From duke at openjdk.org  Tue Sep  2 07:31:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 07:31:28 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v7]
In-Reply-To: <bNwcuUbyoIVgyDcOCbd1AUstDlxERsLNLqJysMfywX0=.6b237132-a623-4d8d-8e11-7dc49bed34a1@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <VVyu6Z5fyjPSoAzCd3xtX7s0qKZBKfwk4kK-iiomyEY=.7a61301b-9d4c-47c7-a887-57a6399caa13@github.com>
 <bNwcuUbyoIVgyDcOCbd1AUstDlxERsLNLqJysMfywX0=.6b237132-a623-4d8d-8e11-7dc49bed34a1@github.com>
Message-ID: <it7oKcYfzHDDuQ0vp_-BIy-EkVSSKigtfANAyDLLsC8=.d494b982-0121-4e21-8869-fb37a6a41b2e@github.com>

On Mon, 1 Sep 2025 21:34:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/os/windows/os_windows.cpp
>>   
>>   8364816: Added _set_errno(0) to avoid reading old values.
>>   
>>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>
> src/hotspot/os/windows/os_windows.cpp line 4823:
> 
>> 4821:       errno = ENOENT;
>> 4822:     } else {
>> 4823:       _set_errno(0);
> 
> I don't object to setting it to zero explicitly but we do not need to use `_set_errno` to do it!
> Suggestion:
> 
>       errno = 0;

Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26901#discussion_r2315171756

From duke at openjdk.org  Tue Sep  2 07:43:27 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 07:43:27 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
Message-ID: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>

Hi, please consider the following changes:

`Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 

Tested in tiers 1 - 3.

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

Commit messages:
 - 8366038: Replaced fence with release_store in Thread::SpinRelease().

Changes: https://git.openjdk.org/jdk/pull/27035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366038
  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27035/head:pull/27035

PR: https://git.openjdk.org/jdk/pull/27035

From dholmes at openjdk.org  Tue Sep  2 07:58:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 07:58:45 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v8]
In-Reply-To: <bZUI7M0PUs80PYJIGvB3jztFXgcRfkMWSQWGLxVN8rY=.df91b9c6-84b8-4279-b642-5d28ea0195db@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <bZUI7M0PUs80PYJIGvB3jztFXgcRfkMWSQWGLxVN8rY=.df91b9c6-84b8-4279-b642-5d28ea0195db@github.com>
Message-ID: <qA2TIx-ozwWxAsIsypGe4DaUPeQB7p5fFwYubvPHlxs=.3a7c5ebc-7258-4c46-9904-b85195c7daa2@github.com>

On Tue, 2 Sep 2025 07:31:28 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os/windows/os_windows.cpp
>   
>   8364816: Changed the way errno is set to zero.
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26901#pullrequestreview-3175317124

From jnordstrom at openjdk.org  Tue Sep  2 08:01:48 2025
From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Tue, 2 Sep 2025 08:01:48 GMT
Subject: Integrated: 8365913: Support latest MSC_VER in abstract_vm_version.cpp
In-Reply-To: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
References: <m96A9c01TCmTDpCCsAt3MdpGXs21kDUW2_GRoziwmBY=.fc9b5e23-218d-4a1e-b882-05e85d7c15fe@github.com>
Message-ID: <kjsmkngfmWHOMOx3nQa2Z5IXX2_-YrwqAWrgpCNryZ0=.38b65e41-6276-4601-ab04-5514eb7578a6@github.com>

On Thu, 21 Aug 2025 09:59:14 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> With the latest devkit upgrade for Windows, hs_err files and `-Xinternalversion` reports "`unknown MS VC++:1943`".
> 
> This fix adds the latest known MSC_VER version, as of current date according to https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170.
> 
> ### Testing
> - [x] Built locally and verified MSVC version is reported correctly
> - [x] tier1-tier3

This pull request has now been integrated.

Changeset: af532cc1
Author:    Joakim Nordstr?m <jnordstrom at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af532cc1b227c56cd03caca7d7558d58687d8584
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8365913: Support latest MSC_VER in abstract_vm_version.cpp

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/26878

From dholmes at openjdk.org  Tue Sep  2 08:04:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 08:04:49 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
In-Reply-To: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
Message-ID: <xtWEJt1QwWDT4LmkgaT9sWDKsNTXOVYBt2kd3JCLr98=.f0f6aa22-d6e4-4a6a-8fea-33171b57ce85@github.com>

On Mon, 1 Sep 2025 14:34:29 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
> 
> Tested in tiers 1 - 3.

Looks good, but I think we can shorten the mega-commentary. Thanks

src/hotspot/share/runtime/thread.cpp line 614:

> 612:   // Conceptually we need a #loadstore|#storestore "release" MEMBAR before
> 613:   // the ST of 0 into the lock-word which releases the lock, so fence
> 614:   // more than covers this on all platforms.

Suggestion:

  // So we need a #loadstore|#storestore "release" memory barrier before
  // the ST of 0 into the lock-word which releases the lock.

src/hotspot/share/runtime/thread.cpp line 616:

> 614:   // more than covers this on all platforms.
> 615:   // However, a full fence is an overkill on most platforms,
> 616:   // the same effect can be achieved with Atomic::release_store().

Suggestion:

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27035#pullrequestreview-3175332019
PR Review Comment: https://git.openjdk.org/jdk/pull/27035#discussion_r2315252612
PR Review Comment: https://git.openjdk.org/jdk/pull/27035#discussion_r2315253345

From duke at openjdk.org  Tue Sep  2 08:06:48 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Sep 2025 08:06:48 GMT
Subject: RFR: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno [v8]
In-Reply-To: <bZUI7M0PUs80PYJIGvB3jztFXgcRfkMWSQWGLxVN8rY=.df91b9c6-84b8-4279-b642-5d28ea0195db@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
 <bZUI7M0PUs80PYJIGvB3jztFXgcRfkMWSQWGLxVN8rY=.df91b9c6-84b8-4279-b642-5d28ea0195db@github.com>
Message-ID: <vT8bg2K880RA-Xwpp3mqzAvikZBMzBaWJzW5MinwGAE=.e41b3ebc-0b26-44af-a6fe-ff632e91f8f1@github.com>

On Tue, 2 Sep 2025 07:31:28 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
>> 
>> Results of `GetLastError()` should be stored into variables of type `DWORD`.
>> 
>> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/os/windows/os_windows.cpp
>   
>   8364816: Changed the way errno is set to zero.
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

@toxaart 
Your change (at version 9d69ac3c83adcbc54493ee9b5c10a5a0b897e953) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26901#issuecomment-3244240884

From duke at openjdk.org  Tue Sep  2 08:08:30 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 08:08:30 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
Message-ID: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>

> Hi, please consider the following changes:
> 
> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
> 
> Tested in tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/runtime/thread.cpp
   
   8366038: Updated comments.
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/runtime/thread.cpp
   
   8366038: Updated comments.
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27035/files
  - new: https://git.openjdk.org/jdk/pull/27035/files/d72316fc..b6daa432

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

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27035/head:pull/27035

PR: https://git.openjdk.org/jdk/pull/27035

From duke at openjdk.org  Tue Sep  2 08:18:49 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 08:18:49 GMT
Subject: Integrated: 8364816: GetLastError() in os_windows.cpp should not store
 value to errno
In-Reply-To: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
References: <-kp4UVOCqF0ZxITA-Rra0t7rWXXC0wLvAnO3OwchPkU=.7873481b-991a-429e-9b4c-9f2c68fec48f@github.com>
Message-ID: <UH8Co9eWfwr_XX45ncP2Ez0u6oFfirt-4Jx2ojjEnaw=.c5b940e5-70f1-447c-a4d4-b77157fae49c@github.com>

On Fri, 22 Aug 2025 12:34:41 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In `os_windows.cpp` in a few places results returned by `GetLastError()` are stored to `errno`. However, `errno` has no relation to `GetLastError()`, and their ranges are not the same.
> 
> Results of `GetLastError()` should be stored into variables of type `DWORD`.
> 
> The removed section in `src/hotspot/share/cds/aotClassLocation.cpp` was relying on values returned by `GetLastError()` and stored to `errno` in `os::stat()`. Though the logic was correct, these values should not be stored to `errno`. The functionality is preserved by storing a **valid** value `ENOENT` to `errno` in `os::stat()`. 
> 
> Tested in tiers 1 - 3.

This pull request has now been integrated.

Changeset: 523bc779
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/523bc77981cfe82956d2176f74917c41788da6db
Stats:     36 lines in 2 files changed: 6 ins; 9 del; 21 mod

8364816: GetLastError() in os_windows.cpp should not store value to errno

Reviewed-by: dholmes, jsikstro

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

PR: https://git.openjdk.org/jdk/pull/26901

From ayang at openjdk.org  Tue Sep  2 08:35:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 2 Sep 2025 08:35:42 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <cfFs58rton8s5izusRpTiivHvAowNR6GBrw9uC9XJe4=.24605b99-7ae9-40e7-9e14-a8288d23eb5a@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27035#pullrequestreview-3175463303

From duke at openjdk.org  Tue Sep  2 09:00:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 2 Sep 2025 09:00:54 GMT
Subject: RFR: 8366660: Sort share/nmt includes
Message-ID: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>

Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.

Passes `tier1`.

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

Commit messages:
 - sort

Changes: https://git.openjdk.org/jdk/pull/27042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27042&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366660
  Stats: 34 lines in 15 files changed: 18 ins; 15 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27042/head:pull/27042

PR: https://git.openjdk.org/jdk/pull/27042

From azafari at openjdk.org  Tue Sep  2 09:02:43 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 2 Sep 2025 09:02:43 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2]
In-Reply-To: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com>
Message-ID: <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com>

On Mon, 1 Sep 2025 13:22:03 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Static assert copy-constructible

Thank you @jdksjolen for taking this issue. 
I have only one concern when we copy a RBTree to a new one. We do a `visit_in_order` on the source tree and `upsert` the key-value to the destination tree. We do a sorted access on both trees. We can avoid one, by  a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)`

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

PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3175564256

From mbaesken at openjdk.org  Tue Sep  2 09:07:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 2 Sep 2025 09:07:04 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing [v2]
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <kFDNwQtrAWcbN_8326EDaRYoHKq-NcneypUWtQy-Zbs=.ced96d07-8c62-4d4d-8b42-c665e7ccc6b0@github.com>

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjustments suggested by Ioi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27001/files
  - new: https://git.openjdk.org/jdk/pull/27001/files/6c777d8d..46b83c89

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

  Stats: 22 lines in 2 files changed: 0 ins; 16 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27001/head:pull/27001

PR: https://git.openjdk.org/jdk/pull/27001

From azeller at openjdk.org  Tue Sep  2 09:13:13 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Tue, 2 Sep 2025 09:13:13 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
Message-ID: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>

The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

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

Commit messages:
 - Ensure test_file gets remove at end of subtest.

Changes: https://git.openjdk.org/jdk/pull/27036/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366558
  Stats: 5 lines in 1 file changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27036/head:pull/27036

PR: https://git.openjdk.org/jdk/pull/27036

From lkorinth at openjdk.org  Tue Sep  2 09:33:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 09:33:00 GMT
Subject: Integrated: 8366666: Bump timeout on StressAsyncUL
Message-ID: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>

Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1"

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

Commit messages:
 - 8366666: Bump timeout on StressAsyncUL

Changes: https://git.openjdk.org/jdk/pull/27044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27044&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366666
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27044/head:pull/27044

PR: https://git.openjdk.org/jdk/pull/27044

From stefank at openjdk.org  Tue Sep  2 09:33:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Sep 2025 09:33:00 GMT
Subject: Integrated: 8366666: Bump timeout on StressAsyncUL
In-Reply-To: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
References: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
Message-ID: <EuWo9vc9mk3ZODz-u-4ZMqY88HwaPYq27GsrZ6nRIWM=.b5b3a4ea-14b7-47ac-9903-8d2d62bdd894@github.com>

On Tue, 2 Sep 2025 09:26:07 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1"

Looks good and trivial. Please push immediately.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27044#pullrequestreview-3175676537

From lkorinth at openjdk.org  Tue Sep  2 09:33:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 09:33:00 GMT
Subject: Integrated: 8366666: Bump timeout on StressAsyncUL
In-Reply-To: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
References: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
Message-ID: <r1udUAElWwHCocRcfMx6DaBIrLOqLJzUP-hrn4M_qKY=.7d644c30-d9cc-487f-882b-d044c3210289@github.com>

On Tue, 2 Sep 2025 09:26:07 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1"

Thanks Stefan!

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

PR Comment: https://git.openjdk.org/jdk/pull/27044#issuecomment-3244533654

From lkorinth at openjdk.org  Tue Sep  2 09:33:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 09:33:00 GMT
Subject: Integrated: 8366666: Bump timeout on StressAsyncUL
In-Reply-To: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
References: <S3668MxK5JHhV1BmVEtUYgf6-MhW2R0pKmx5SbMwU_4=.b978de80-700d-475b-83df-7a9568d9b68d@github.com>
Message-ID: <DSo8zO20yflzMPsMZplPAZK9_NitNlJQQFDuRySR-rA=.cc27a45a-dd6c-49b4-ba80-9b5834072a5a@github.com>

On Tue, 2 Sep 2025 09:26:07 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Timeout after "8260555: Change the default TIMEOUT_FACTOR from 4 to 1"

This pull request has now been integrated.

Changeset: e66ed4d7
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e66ed4d72948a56863f2979b976ef81c0fc43f75
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8366666: Bump timeout on StressAsyncUL

Reviewed-by: stefank

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

PR: https://git.openjdk.org/jdk/pull/27044

From cnorrbin at openjdk.org  Tue Sep  2 09:39:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 2 Sep 2025 09:39:44 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2]
In-Reply-To: <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com>
 <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com>
Message-ID: <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com>

On Tue, 2 Sep 2025 09:00:19 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> We can avoid one, by a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)`

I don't think we would see much improvement iterating differently on the source tree. However, for the destination tree we traverse down the tree for each upsert, which could have quite an impact on large trees. `hint_node` decides where to start searching from, so if we cache the previous node we can avoid this traversal and start directly at the insert point.

To achieve this we could change the return type of `upsert` from `void` to `RBNode<K, V>*`, which is easily done and change the copy-constructor to something like:
```c++
  RBTree(const RBTree& other) : BaseType(), _allocator() {
    static_assert(std::is_copy_constructible<K>::value, "Key type must be copy-constructible when copying a RBTree");
    static_assert(std::is_copy_constructible<V>::value, "Value type must be copy-constructible when copying a RBTree");
    RBNode<K, V>* prev_node = nullptr;
    other.visit_in_order([&](RBNode<K, V>* node) {
      RBNode<K, V>* new_node = this->upsert(node->key(), node->val(), prev_node);
      prev_node = new_node;
      return true;
    });
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244565428

From jsjolen at openjdk.org  Tue Sep  2 09:44:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 09:44:42 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2]
In-Reply-To: <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com>
 <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com>
 <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com>
Message-ID: <C9fDYWJ5LQU5q-a9sdi04B6CQOOSySvncCDJ9oQCbKU=.f05145ef-f2b3-49bf-b1dc-8f129c3f734a@github.com>

On Tue, 2 Sep 2025 09:37:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> > We can avoid one, by a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)`
> 
> I don't think we would see much improvement iterating differently on the source tree. However, for the destination tree we traverse down the tree for each upsert, which could have quite an impact on large trees. `hint_node` decides where to start searching from, so if we cache the previous node we can avoid this traversal and start directly at the insert point.
> 
> To achieve this we could change the return type of `upsert` from `void` to `RBNode<K, V>*`, which is easily done and change the copy-constructor to something like:
> 
> ```c++
>   RBTree(const RBTree& other) : BaseType(), _allocator() {
>     static_assert(std::is_copy_constructible<K>::value, "Key type must be copy-constructible when copying a RBTree");
>     static_assert(std::is_copy_constructible<V>::value, "Value type must be copy-constructible when copying a RBTree");
>     RBNode<K, V>* prev_node = nullptr;
>     other.visit_in_order([&](RBNode<K, V>* node) {
>       RBNode<K, V>* new_node = this->upsert(node->key(), node->val(), prev_node);
>       prev_node = new_node;
>       return true;
>     });
>   }
> ```

I think we need to switch out the iterator for that to make sense, specifically it needs to be DFS. Anyway, let's do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244581331

From azafari at openjdk.org  Tue Sep  2 09:56:45 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 2 Sep 2025 09:56:45 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3]
In-Reply-To: <AT-fAKCyc1z07jTOkqB5DmVY8yyyqWlJgsArRE71zFg=.5e2ecbfb-552e-4bb6-ab60-5545f3945311@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <AT-fAKCyc1z07jTOkqB5DmVY8yyyqWlJgsArRE71zFg=.5e2ecbfb-552e-4bb6-ab60-5545f3945311@github.com>
Message-ID: <WWRzczCVa1EDxmWzJO9M4WmfMc20zyQkToBScO3SdEU=.f4ae08eb-e503-4b8b-9bb0-60d7092774af@github.com>

On Tue, 2 Sep 2025 07:03:27 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

When we do a `visit_in_order` we can set `next(right node)` of new nodes one by one. IOW, since Key-Values are retrieved in order, we can insert them one after another. Right?
Inspired by the `visit_in_order()` itself: there we first get `leftmost()` and then use `next()` in a loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244624236

From ayang at openjdk.org  Tue Sep  2 10:03:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 2 Sep 2025 10:03:42 GMT
Subject: RFR: 8366660: Sort share/nmt includes
In-Reply-To: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
References: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
Message-ID: <BkYZt52hNAugQZIEHkka1VpmCeUouLnBmACT0iXbON0=.66eb56e1-c396-4dc7-bbf3-f370644d5941@github.com>

On Tue, 2 Sep 2025 08:55:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.
> 
> Passes `tier1`.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27042#pullrequestreview-3175812928

From jsjolen at openjdk.org  Tue Sep  2 11:13:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:13:45 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v4]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <4bty3Tqy3pgig2fRDijwX1frSvNQxXbYNgxQ6GVWQWE=.2df02b1e-022f-4e43-a9e4-8e1b7bd57d1b@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Rewrite copying entirely

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/800eca26..2e7bd8c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=02-03

  Stats: 80 lines in 5 files changed: 40 ins; 18 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 11:23:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:23:01 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v5]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <ycHnpVBUtsY1hTUTbxiw1B17PgUO2NLQ6r0JU29mTsg=.798fd06b-29aa-4dbc-8e9a-5f0a194aad13@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Fix
 - Fix the NodeType*

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/2e7bd8c9..69c65fe1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 11:28:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:28:03 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v6]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <G7t0ghV2Jtjnte6SelEcCIxwvtsOHrsM9XsIQPl2_Sc=.050c02ac-361b-4917-8b76-0f1f29185915@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  It's const

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/69c65fe1..7deb9a1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 11:33:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:33:21 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v7]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <yeU56iQiRLA72wj22INpcABTuCFnDP_3-q-y4EmBBEE=.e1885c5a-9cb2-459b-bca4-3f6ba5869a7b@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/7deb9a1b..7c3f1a41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 11:44:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:44:01 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v8]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <Wp3IBZPXxMAVM89XWTemYNcvQvbd0Lq_7Pu8ZIosq0s=.d709fd2e-40ca-4c16-a0ed-6ec652c8107d@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Aha, missing include
 - Wait, the VMATree is wrong?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/7c3f1a41..1cceebf2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=06-07

  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From mbaesken at openjdk.org  Tue Sep  2 11:49:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 2 Sep 2025 11:49:46 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <m_jZUO4yM452OHwkXDq7ToDOKWowY-kcbC48N9qSYfI=.c82789eb-fbc6-482b-a612-be644d80fac2@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

Thanks for fixing !

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27036#pullrequestreview-3176179927

From jsjolen at openjdk.org  Tue Sep  2 11:54:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:54:19 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <v1FnSSstSMpMR2kLFsdgy7tqIHE7VPmn7-OjYvqxymU=.d37a0dfd-be30-4cd0-a843-ed0464d29f26@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision:

 - Yup
 - Some more ugly casts
 - Aha, _root is typed as an IntrusiveRBNode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/1cceebf2..04b5a99b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=07-08

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Tue Sep  2 11:56:43 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 11:56:43 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v8]
In-Reply-To: <Wp3IBZPXxMAVM89XWTemYNcvQvbd0Lq_7Pu8ZIosq0s=.d709fd2e-40ca-4c16-a0ed-6ec652c8107d@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <Wp3IBZPXxMAVM89XWTemYNcvQvbd0Lq_7Pu8ZIosq0s=.d709fd2e-40ca-4c16-a0ed-6ec652c8107d@github.com>
Message-ID: <YES4W5YtNwkXJ6RJE27dGg8ubxq0NLnSBosPC2nbMJw=.33772fe7-e6a7-4695-91a1-48c2e0c0581e@github.com>

On Tue, 2 Sep 2025 11:44:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Aha, missing include
>  - Wait, the VMATree is wrong?

Sorry about the ridiculous amount of commits. For each one I thought "this is the last one". I've created a temp branch that I'll push to so you don't have to see this WIP.

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3245001621

From dholmes at openjdk.org  Tue Sep  2 12:31:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Sep 2025 12:31:42 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <IrvxmqDrYqRc_Kv21Jz2kBc9hjJICjZNNGIXhLR8Sjo=.2c105b02-8ca7-4733-95fe-a1fa9fc5aabf@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27035#pullrequestreview-3176327861

From stuefe at openjdk.org  Tue Sep  2 12:36:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 Sep 2025 12:36:43 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <csApVZqvDbiCYtJsKfZSdHeNEOGfRWjFV33U7mP5bt8=.f1c8dd60-2f1e-4bc7-9c5d-2e4d5340800c@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

LGTM

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27036#pullrequestreview-3176345959

From shade at openjdk.org  Tue Sep  2 12:57:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Sep 2025 12:57:41 GMT
Subject: RFR: 8366660: Sort share/nmt includes
In-Reply-To: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
References: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
Message-ID: <edSJvoxKhlRI4JxoLF3zdnBilUCBrPFJTKgnAtzmaVg=.22013ff6-22c3-4b06-93e0-c1f6d1d7ee42@github.com>

On Tue, 2 Sep 2025 08:55:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.
> 
> Passes `tier1`.

Looks fine, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27042#pullrequestreview-3176429644

From duke at openjdk.org  Tue Sep  2 12:58:46 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 12:58:46 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <nhSSzfnOLqYOe4Nivte9GRn7z3OS5b4SAoTPKjv1i0c=.c54d77f2-b508-4469-80eb-9030b3bf3871@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thanks for reviews, let's

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

PR Comment: https://git.openjdk.org/jdk/pull/27035#issuecomment-3245217087

From duke at openjdk.org  Tue Sep  2 12:58:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Sep 2025 12:58:47 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <ajRgabLW26JNBSj8lSBurXOiadvJMA0dbajcg1jHtDk=.846027dc-ca08-4fc5-a6fd-8d771003a43d@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

@toxaart 
Your change (at version b6daa43252f31a4069a524d04a81996b1342b389) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27035#issuecomment-3245219486

From duke at openjdk.org  Tue Sep  2 13:00:42 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Sep 2025 13:00:42 GMT
Subject: RFR: 8366660: Sort share/nmt includes
In-Reply-To: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
References: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
Message-ID: <9S-SYXpu3gc5AheoecgAD3tqA49CO7ylEMvsgwQYahM=.11565cd2-c707-42be-8d34-2221aefc178e@github.com>

On Tue, 2 Sep 2025 08:55:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.
> 
> Passes `tier1`.

@fandreuz 
Your change (at version ab22f2c20c460da05da4d871334dc0ae917db255) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27042#issuecomment-3245225859

From shade at openjdk.org  Tue Sep  2 13:03:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Sep 2025 13:03:41 GMT
Subject: RFR: 8366660: Sort share/nmt includes
In-Reply-To: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
References: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
Message-ID: <_HZ9LLgHkXEKD78hJ_Esat1EiS-uEy3mdbQbBfP1y9w=.b08bb243-9aef-449b-b99d-530a7a3d6280@github.com>

On Tue, 2 Sep 2025 08:55:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.
> 
> Passes `tier1`.

Yeah, wait 24 hours. This is borderline trivial, but there is no need to rush.

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

PR Comment: https://git.openjdk.org/jdk/pull/27042#issuecomment-3245234761

From shade at openjdk.org  Tue Sep  2 13:06:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Sep 2025 13:06:54 GMT
Subject: RFR: 8366483: ShowRegistersOnAssertTest uses wrong register
 pattern string for Windows on AArch64
In-Reply-To: <teo3iW7a4TWDV0oW_2j78UsVPAOGE5196k6snEWitL0=.1e074d95-3d12-4799-a2a6-94e9bdff33ef@github.com>
References: <V28OqhZx6dxbkVwiRMWnFDSy1jbOkZxPfRmOuXx9fQU=.47be71b3-36da-4e03-b898-bc37594ce90d@github.com>
 <b2b3n1I9fdWH6Yfp_OQ5lw60mh9NaH66BENLsnfuY4I=.88a7633c-f393-48db-ae96-655b50678b19@github.com>
 <iPcxYGcnd9D7sCWITCiAu0RC_HDAFNm5Do-ytZdBoIU=.99c40d31-e061-4ac1-8f55-b3339f30d09b@github.com>
 <teo3iW7a4TWDV0oW_2j78UsVPAOGE5196k6snEWitL0=.1e074d95-3d12-4799-a2a6-94e9bdff33ef@github.com>
Message-ID: <j41n5W0xAxbv8yhv-t7PWuwhnRgz6REwPWZWtIJOySQ=.1dc8e39b-6450-4f5e-a35a-b1c511548119@github.com>

On Tue, 2 Sep 2025 04:01:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But is that Windows specific? I'm wondering why Windows-Aarch64 uses X whereas Linux-aarch64 uses R.

I don't think `X` or `R` are any special here, both are fine. We can, of course, draw the line in the sand and do `R` everywhere in Hotspot for extra consistency.

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

PR Comment: https://git.openjdk.org/jdk/pull/27022#issuecomment-3245251318

From phubner at openjdk.org  Tue Sep  2 13:08:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 2 Sep 2025 13:08:50 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9]
In-Reply-To: <v1FnSSstSMpMR2kLFsdgy7tqIHE7VPmn7-OjYvqxymU=.d37a0dfd-be30-4cd0-a843-ed0464d29f26@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <v1FnSSstSMpMR2kLFsdgy7tqIHE7VPmn7-OjYvqxymU=.d37a0dfd-be30-4cd0-a843-ed0464d29f26@github.com>
Message-ID: <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com>

On Tue, 2 Sep 2025 11:54:19 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Yup
>  - Some more ugly casts
>  - Aha, _root is typed as an IntrusiveRBNode

src/hotspot/share/utilities/rbTree.hpp line 464:

> 462:     struct node_pair { const RBNode<K, V>* current; RBNode<K, V>* other_parent; Dir d; };
> 463:     struct stack {
> 464:       node_pair s[64];

Could you clarify the choice of 64 as an upper bound? It's not immediately obvious to me if we guarantee (or if we don't care about) the maximum visitation size in the code below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316036406

From jsjolen at openjdk.org  Tue Sep  2 13:18:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 13:18:44 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9]
In-Reply-To: <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <v1FnSSstSMpMR2kLFsdgy7tqIHE7VPmn7-OjYvqxymU=.d37a0dfd-be30-4cd0-a843-ed0464d29f26@github.com>
 <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com>
Message-ID: <0QdMYssbmrxll76glB1s9PS55PFbkULHq-ezpr5b5B4=.2b8d7971-14d5-4cf4-bc5f-41a2aaa89d5d@github.com>

On Tue, 2 Sep 2025 13:06:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Yup
>>  - Some more ugly casts
>>  - Aha, _root is typed as an IntrusiveRBNode
>
> src/hotspot/share/utilities/rbTree.hpp line 464:
> 
>> 462:     struct node_pair { const RBNode<K, V>* current; RBNode<K, V>* other_parent; Dir d; };
>> 463:     struct stack {
>> 464:       node_pair s[64];
> 
> Could you clarify the choice of 64 as an upper bound? It's not immediately obvious to me if we guarantee (or if we don't care about) the maximum visitation size in the code below.

It's an arbitrary depth (it's used in other parts of the RBTree code as well). The maximum length of the stack represents the maximum depth of the tree that we support. A perfectly balanced binary tree of depth 64 has 2**64 - 1 nodes, so in practice this will never be reached.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316065902

From jsjolen at openjdk.org  Tue Sep  2 13:30:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 13:30:59 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <JaRvP2c2skKCmaW_87H1nF7yzhkObXl5aVWCgzJ6aVg=.4cda6389-0d97-4194-80bf-e5ffe891a668@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  After a lot of casting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/04b5a99b..76ec83f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=08-09

  Stats: 55 lines in 2 files changed: 42 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From azafari at openjdk.org  Tue Sep  2 13:58:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 2 Sep 2025 13:58:10 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10]
In-Reply-To: <JaRvP2c2skKCmaW_87H1nF7yzhkObXl5aVWCgzJ6aVg=.4cda6389-0d97-4194-80bf-e5ffe891a668@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <JaRvP2c2skKCmaW_87H1nF7yzhkObXl5aVWCgzJ6aVg=.4cda6389-0d97-4194-80bf-e5ffe891a668@github.com>
Message-ID: <zdt_mJEljfJMUDyujw93oCLAczrHiKi1ohLwLOhJ7Rk=.a5ca9d84-eb74-46e5-a35f-c9a3ffed1f2d@github.com>

On Tue, 2 Sep 2025 13:30:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After a lot of casting

src/hotspot/share/nmt/memBaseline.cpp line 175:

> 173:   VirtualMemoryAllocationSite* site;
> 174:   bool failed_oom = false;
> 175:   _vma_allocs_replacement->visit_reserved_regions([&](ReservedMemoryRegion& rgn) {

The `_vma_allocs_replacement` is used only locally here. Instead of creating a copy of the VMATree, we can do our loop here within a lock. Can't we?
Then we save one tree traverse.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316165798

From jsjolen at openjdk.org  Tue Sep  2 13:58:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 13:58:10 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10]
In-Reply-To: <zdt_mJEljfJMUDyujw93oCLAczrHiKi1ohLwLOhJ7Rk=.a5ca9d84-eb74-46e5-a35f-c9a3ffed1f2d@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <JaRvP2c2skKCmaW_87H1nF7yzhkObXl5aVWCgzJ6aVg=.4cda6389-0d97-4194-80bf-e5ffe891a668@github.com>
 <zdt_mJEljfJMUDyujw93oCLAczrHiKi1ohLwLOhJ7Rk=.a5ca9d84-eb74-46e5-a35f-c9a3ffed1f2d@github.com>
Message-ID: <EJkCL2kDBjjp6KMEARbJac_hr8l6mHAhSJth3Y5gHqo=.74bf617b-b90e-4063-aebc-fe80a78b0c3a@github.com>

On Tue, 2 Sep 2025 13:51:47 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After a lot of casting
>
> src/hotspot/share/nmt/memBaseline.cpp line 175:
> 
>> 173:   VirtualMemoryAllocationSite* site;
>> 174:   bool failed_oom = false;
>> 175:   _vma_allocs_replacement->visit_reserved_regions([&](ReservedMemoryRegion& rgn) {
> 
> The `_vma_allocs_replacement` is used only locally here. Instead of creating a copy of the VMATree, we can do our loop here within a lock. Can't we?
> Then we save one tree traverse.

It's used here:

```c++
void MemDetailReporter::report_virtual_memory_map() {
  // Virtual memory map always in base address order
  output()->print_cr("Virtual memory map:");
  _baseline.virtual_memory_allocations()->visit_reserved_regions([&](ReservedMemoryRegion& rgn) {
    report_virtual_memory_region(&rgn);
    return true;
  });
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316171652

From jsjolen at openjdk.org  Tue Sep  2 13:58:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 2 Sep 2025 13:58:10 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v11]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <OEoFNFR8I7Vg5hCT_8Jpcr33iFDLp6y_V02YcloCnzM=.ad75e52f-1f97-40e3-9a87-fd1a12c8c35b@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Rename to _vma_allocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/76ec83f9..ac24b5e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=09-10

  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From kbarrett at openjdk.org  Tue Sep  2 14:37:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Sep 2025 14:37:43 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <X6Tk5RyvnjRf1liB9Gn8dEImWObzBsnEB7j2apnWG5k=.68248f16-5ccf-4a54-9429-1b73dd1144b6@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

> Thanks for reviews, let's /integrate

OpenJDK changes (not just HotSpot changes) should generally be open for 24 hours before being integrated.
https://openjdk.org/guide/ > Life of a PR > 7. Allow enough time for review

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

PR Comment: https://git.openjdk.org/jdk/pull/27035#issuecomment-3245624272

From duke at openjdk.org  Tue Sep  2 15:29:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 2 Sep 2025 15:29:44 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <X6Tk5RyvnjRf1liB9Gn8dEImWObzBsnEB7j2apnWG5k=.68248f16-5ccf-4a54-9429-1b73dd1144b6@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
 <X6Tk5RyvnjRf1liB9Gn8dEImWObzBsnEB7j2apnWG5k=.68248f16-5ccf-4a54-9429-1b73dd1144b6@github.com>
Message-ID: <Ys5qwU6E6CN-zszctUkyy2qN0wuqaVA2HGuNSppXLKU=.2ec3b338-46d3-4be5-88c6-112811db1e14@github.com>

On Tue, 2 Sep 2025 14:35:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Thanks for reviews, let's /integrate
> 
> OpenJDK changes (not just HotSpot changes) should generally be open for 24 hours before being integrated. https://openjdk.org/guide/ > Life of a PR > 7. Allow enough time for review

Right, I looked at the timestamp of the commit, not when the PR was marked as RFR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27035#issuecomment-3245821718

From lkorinth at openjdk.org  Tue Sep  2 16:42:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 16:42:21 GMT
Subject: RFR: 8366704: Bump timeout on TestInheritFD
Message-ID: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>

I missed bumping the manual timeout on the subprocess. It is now 60 seconds, just as before the change of the timeout factor.

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

Commit messages:
 - 8366704: Bump timeout on TestInheritFD

Changes: https://git.openjdk.org/jdk/pull/27057/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366704
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27057/head:pull/27057

PR: https://git.openjdk.org/jdk/pull/27057

From lmesnik at openjdk.org  Tue Sep  2 17:00:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Sep 2025 17:00:44 GMT
Subject: RFR: 8366704: Bump timeout on TestInheritFD
In-Reply-To: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
References: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
Message-ID: <afzwUFsJCKrsOvGXICm_ZQ3J0m11QA88XR0LGLUZCqI=.c45888e0-8b0c-446c-8c17-bd6bfff5c06f@github.com>

On Tue, 2 Sep 2025 16:36:01 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I missed bumping the manual timeout on the subprocess. It is now 60 seconds, just as before the change of the timeout factor.

Thanks for quick fix. The fix looks trivial to me.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27057#pullrequestreview-3177410742

From lkorinth at openjdk.org  Tue Sep  2 17:00:46 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 17:00:46 GMT
Subject: RFR: 8366704: Bump timeout on TestInheritFD
In-Reply-To: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
References: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
Message-ID: <vG8rbARNed0-uZap6EZntwKpF2clLR3jcr07Fh7H6dA=.9ae31420-04d4-4808-9584-5a9dd803f69e@github.com>

On Tue, 2 Sep 2025 16:36:01 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I missed bumping the manual timeout on the subprocess. It is now 60 seconds, just as before the change of the timeout factor.

Thanks Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/27057#issuecomment-3246113373

From lkorinth at openjdk.org  Tue Sep  2 17:03:47 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 17:03:47 GMT
Subject: Integrated: 8366704: Bump timeout on TestInheritFD
In-Reply-To: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
References: <6jyc48E_DXk4DgVkvJF5HPZG83V-bkETuWkZHNqe4aA=.0e6e317d-0958-424b-918f-8715a13ba1a6@github.com>
Message-ID: <Hd6dwbVL_jFdLFvMQkQjse2GopV-5_7NcIAFZnt5hEA=.06589d1d-cd95-4b6f-baaa-235461323bf9@github.com>

On Tue, 2 Sep 2025 16:36:01 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I missed bumping the manual timeout on the subprocess. It is now 60 seconds, just as before the change of the timeout factor.

This pull request has now been integrated.

Changeset: 48ba8ed2
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48ba8ed2439f9a4a5cdca8715ffddad377366347
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8366704: Bump timeout on TestInheritFD

Reviewed-by: lmesnik

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

PR: https://git.openjdk.org/jdk/pull/27057

From iklam at openjdk.org  Tue Sep  2 19:23:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Sep 2025 19:23:44 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing [v2]
In-Reply-To: <kFDNwQtrAWcbN_8326EDaRYoHKq-NcneypUWtQy-Zbs=.ced96d07-8c62-4d4d-8b42-c665e7ccc6b0@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <kFDNwQtrAWcbN_8326EDaRYoHKq-NcneypUWtQy-Zbs=.ced96d07-8c62-4d4d-8b42-c665e7ccc6b0@github.com>
Message-ID: <wRruQB21BmhyKfjUa2txhyca8hRlub4el5KPxCpAkR4=.09810dc8-7bc5-4eac-a466-ad5dfd94d245@github.com>

On Tue, 2 Sep 2025 09:07:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We fail in one of our test setups with this output :
>> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
>> 
>> 
>>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] CDS is incompatible with other specified options.
>> Error occurred during initialization of VM
>> Unable to use shared archive: invalid archive
>> ];
>>  stderr: []
>>  exitValue = 1
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
>> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
>> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
>> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
>> at AOTMapTest.doTest(AOTMapTest.java:71)
>> at AOTMapTest.main(AOTMapTest.java:61)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1474)
>> 
>> 
>> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments suggested by Ioi

I am running your patch (minus the vm.cds.default.archive.available line) in our CI tiers 1-4 to make sure the test works with vm flag rotation.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java line 39:

> 37:  * @bug 8362566
> 38:  * @summary Test the contents of -Xlog:aot+map with AOT workflow
> 39:  * @requires vm.cds.default.archive.available

I think this is not needed anymore.

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3177827025
PR Review Comment: https://git.openjdk.org/jdk/pull/27001#discussion_r2316957032

From dlong at openjdk.org  Tue Sep  2 20:52:32 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 20:52:32 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

Dean Long has updated the pull request incrementally with three additional commits since the last revision:

 - revert whitespace change
 - undo debug changes
 - cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27059/files
  - new: https://git.openjdk.org/jdk/pull/27059/files/303305ae..eac482a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=01-02

  Stats: 7 lines in 4 files changed: 1 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059

PR: https://git.openjdk.org/jdk/pull/27059

From vlivanov at openjdk.org  Tue Sep  2 21:11:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 2 Sep 2025 21:11:46 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

Nice cleanup! Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3178139499

From dlong at openjdk.org  Tue Sep  2 22:16:44 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 2 Sep 2025 22:16:44 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
Message-ID: <Qs9S_gOm2lAwk5iQCgkL_VglUnqegw7tuI8rjVdJ2hg=.6a5633c7-910f-4bb4-9866-ffb6e5c2b0d1@github.com>

On Tue, 2 Sep 2025 21:09:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> Nice cleanup! Looks good.

Thanks @iwanowww !

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3246957430

From duke at openjdk.org  Wed Sep  3 06:47:48 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 3 Sep 2025 06:47:48 GMT
Subject: Integrated: 8366660: Sort share/nmt includes
In-Reply-To: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
References: <l-dU2iiGoOGzzEVQYk8sdTHVgDcUn2vHKHbCnToHiEQ=.357f4462-9f9d-4c9e-b003-ce55c7351196@github.com>
Message-ID: <nIvIm7UYgytV8DNdNKxoPabKxQpNJRYg_Po4Kg_-fKk=.f803d3de-50c3-497d-ae94-e07dfd64ccf7@github.com>

On Tue, 2 Sep 2025 08:55:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Sort include statements in `hotspot/share/nmt` using `SortIncludes.java`. I'm also removing a couple unnecessary includes.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 7c70e734
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c70e7341438ce8a420021005a0f03fe917e5a26
Stats:     34 lines in 15 files changed: 18 ins; 15 del; 1 mod

8366660: Sort share/nmt includes

Reviewed-by: ayang, shade

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

PR: https://git.openjdk.org/jdk/pull/27042

From mhaessig at openjdk.org  Wed Sep  3 07:17:44 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 3 Sep 2025 07:17:44 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

Thank you for cleaning this up, @dean-long. I just have a drive-by comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372:

> 370:         // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp));
> 371:       }
> 372:     }

`<arch>Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well?

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

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3179245014
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2317990499

From azafari at openjdk.org  Wed Sep  3 08:08:52 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 3 Sep 2025 08:08:52 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v6]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <qwpr6h_9Yk9a-iK5QtP8091W7-MiUeTyEIeXxyOjXLI=.ba22b0b3-b99f-4942-9fe0-be62ef71d920@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  message fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/5854ef36..0b532758

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26859/head:pull/26859

PR: https://git.openjdk.org/jdk/pull/26859

From mbaesken at openjdk.org  Wed Sep  3 08:29:28 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Sep 2025 08:29:28 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing [v3]
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove requires

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27001/files
  - new: https://git.openjdk.org/jdk/pull/27001/files/46b83c89..6abf2516

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27001&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27001&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27001/head:pull/27001

PR: https://git.openjdk.org/jdk/pull/27001

From jsjolen at openjdk.org  Wed Sep  3 09:12:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 3 Sep 2025 09:12:44 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline
 - Rename to _vma_allocations
 - After a lot of casting
 - Yup
 - Some more ugly casts
 - Aha, _root is typed as an IntrusiveRBNode
 - Aha, missing include
 - Wait, the VMATree is wrong?
 - Rename
 - It's const
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b

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

Changes: https://git.openjdk.org/jdk/pull/27003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=11
  Stats: 226 lines in 11 files changed: 161 ins; 44 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Wed Sep  3 09:18:51 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 3 Sep 2025 09:18:51 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12]
In-Reply-To: <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
Message-ID: <xLiMf9uu31g_1KDfkQ-a9LdfzJe0D1rT8WyznY5TU88=.bff5c73b-95da-45c8-8010-39408cfd6e60@github.com>

On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline
>  - Rename to _vma_allocations
>  - After a lot of casting
>  - Yup
>  - Some more ugly casts
>  - Aha, _root is typed as an IntrusiveRBNode
>  - Aha, missing include
>  - Wait, the VMATree is wrong?
>  - Rename
>  - It's const
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b

GHA is a bit borked.

>Error: Failed to resolve action download info.
Error: Failed to resolve action download info.

I re-ran the failed tests of the previous GHA run on my local instance and those tests did not fail. Not sure if it was a fluke, or if we have an actual issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3248401792

From duke at openjdk.org  Wed Sep  3 10:07:48 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Sep 2025 10:07:48 GMT
Subject: RFR: 8366038: Thread::SpinRelease should use Atomic::release_store
 [v2]
In-Reply-To: <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
 <4-bw3R3BzelADRN27rGHYHHO_x_NvnuayJ5SdvqI06s=.3521d5ba-e5a5-492b-badd-e7bcd914360a@github.com>
Message-ID: <GLS6aIe5_fVbYLxJj5bnQHvfgIQrK55A_DFxzmOX7s8=.7b6c97d2-e696-4168-9d6d-2727b577f5c3@github.com>

On Tue, 2 Sep 2025 08:08:30 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
>> 
>> Tested in tiers 1 - 3.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/thread.cpp
>    
>    8366038: Updated comments.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

@toxaart 
Your change (at version b6daa43252f31a4069a524d04a81996b1342b389) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27035#issuecomment-3248580159

From duke at openjdk.org  Wed Sep  3 10:09:45 2025
From: duke at openjdk.org (mazhen)
Date: Wed, 3 Sep 2025 10:09:45 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>
Message-ID: <wgVEn4VJFH4IepzJqs9uzE8ptA3TvuqXPqIX0jGCH4E=.8c256a04-dbc6-445e-85e6-fc9697602d69@github.com>

On Mon, 1 Sep 2025 04:32:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would suggest filing a new bug for the CentOS hang and create a new PR of the change here, with that new bug ID.

Thank you, that plan sounds great.

I don't yet have an account on bugs.openjdk.org to file the new bug.

Would you mind creating the JBS issue for this hang? I've drafted all the necessary information below to help.

---

### **Suggested JBS Issue Content**

**Title:**
`runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms`

**Description:**

The `TestStackGuardPagesNative.java` test hangs and times out on some Linux distributions (e.g., CentOS 7) during the `test_native_overflow_initial` scenario.

This issue is a regression introduced by the "hardening" fix in `JDK-8295344`. That fix correctly replaced a recursive implementation in `exeinvoke.c` (which caused stack corruption, see `JDK-8293452`) with an iterative `for(;;)` loop.

However, this unbounded loop relies on an incidental `SIGSEGV` (e.g., `SEGV_MAPERR`) to terminate. On platforms like CentOS 7, this signal does not occur in a timely manner, causing the native process to hang indefinitely.

The proposed solution is to make the iterative loop bounded by checking against the previously recorded overflow depth (`_kp_rec_count`). This retains the benefit of the iterative approach (no stack corruption) while fixing the hang, making the test's behavior deterministic and platform-independent.

---

Once the new bug ID is available, I will close this current PR and open a new one with the fix, linked to the new ID, as you suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3248587960

From syan at openjdk.org  Wed Sep  3 10:40:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 10:40:44 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <wgVEn4VJFH4IepzJqs9uzE8ptA3TvuqXPqIX0jGCH4E=.8c256a04-dbc6-445e-85e6-fc9697602d69@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>
 <wgVEn4VJFH4IepzJqs9uzE8ptA3TvuqXPqIX0jGCH4E=.8c256a04-dbc6-445e-85e6-fc9697602d69@github.com>
Message-ID: <_drvb0p_XQGA9lKy7BhZf0BVmK4v0gJBfP0RtiGvkN0=.0c24aeb8-be07-4ff8-a13e-faa7bf374574@github.com>

On Wed, 3 Sep 2025 10:07:28 GMT, mazhen <duke at openjdk.org> wrote:

> Once the new bug ID is available, I will close this current PR and open a new one with the fix, linked to the new ID, as you suggested.

I have created a new issue https://bugs.openjdk.org/browse/JDK-8366787

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3248691290

From coleenp at openjdk.org  Wed Sep  3 11:28:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 11:28:45 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v3]
In-Reply-To: <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
Message-ID: <MKvfwvSuMWU9nJk1i0OvTUYuqUVgVVls2w6XFqkOV9o=.494d3ed6-332f-4807-887b-9cd3ea9a4a98@github.com>

On Mon, 1 Sep 2025 07:55:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed test-only assert

It's a minor point really but while you're making this logic less confusing, might as well fix the extra else.

src/hotspot/share/classfile/classFileParser.cpp line 5770:

> 5768:                        "java.lang.Object cannot implement an interface in class file %s",
> 5769:                        CHECK);
> 5770:   }

This is somewhat strange logic.  Seems like there should be an assert that _super_klass == nullptr then an 'else' at 5779 and an assert that _super_class_index != 0.  The trailing else is confusing and it checks something here at 5775.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3180189082
PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2318661824

From coleenp at openjdk.org  Wed Sep  3 11:28:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 11:28:46 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <LqtMMBDoD9LlxZzSINgKLF6ylVjMYUlS9_MptG0sE2k=.1172df57-4f9f-4f92-aa36-42f2a0e1159b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
 <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>
 <wUuHNQ-Eq5davnomMuo-H_YGZXVfyj-DTInMXUD_wNw=.418016f0-2655-4243-bd2e-dad31d4d9dd8@github.com>
 <LqtMMBDoD9LlxZzSINgKLF6ylVjMYUlS9_MptG0sE2k=.1172df57-4f9f-4f92-aa36-42f2a0e1159b@github.com>
Message-ID: <4Zg07AzzEhPyY-yTvuB34OSUNSaxyePJnZKRZikW5JQ=.4eb7e85c-2194-474d-8921-c259c1b8ccd4@github.com>

On Mon, 1 Sep 2025 08:01:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I would just have:
>> 
>> else {
>>   // The class is Object - so no superclass
>> }
>
> My asserts say the same thing, except they comes with proofs that they are not lying.

I don't like the 'else' either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2318663154

From jsjolen at openjdk.org  Wed Sep  3 12:21:46 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 3 Sep 2025 12:21:46 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks. [v4]
In-Reply-To: <SYGF5A7yQYsBkplGSJTKxGGAivSkIANwAdt33MIzMvo=.9d5984b2-1eae-4fe3-a5d0-fb7d02d4984d@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <SYGF5A7yQYsBkplGSJTKxGGAivSkIANwAdt33MIzMvo=.9d5984b2-1eae-4fe3-a5d0-fb7d02d4984d@github.com>
Message-ID: <XnhAsxdq2y9MTkST3_9H7MwKDTgm2hKEfge4IAjg-4M=.497e9bcc-d780-438e-bd21-64b8413ab001@github.com>

On Mon, 1 Sep 2025 13:40:28 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current red-black tree can be made safer, and its inspection capabilities improved.
>> 
>> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
>> 
>> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
>> 
>> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
>> 
>> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
>> 
>> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   johan feedback

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3180371207

From jbechberger at openjdk.org  Wed Sep  3 14:22:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 3 Sep 2025 14:22:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <qSUpiA5KWqYjdnu2fhdurDwOjdeqA8kzHZ8FFt6YtzI=.b64a7d51-540e-46fc-968e-3a41255cf464@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Regarding files:

`-Xlog:jfr+startup=info:file=a.txt` causes the startup message to be written to the file, but `-Xlog:jfr+startup=warning:file=a.txt` doesn't.

So it works both for files and stdout, the implementation changes the behaviour at the root.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3249467266

From duke at openjdk.org  Wed Sep  3 14:51:05 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Wed, 3 Sep 2025 14:51:05 GMT
Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on
 Windows aarch64
Message-ID: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>

The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change.

Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler.

Exceptions with the DBG_PRINTEXCEPTION_C  exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code)

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

Commit messages:
 - Fix bug causing missing core dumps on Windows AArch64
 - Windows AArch64 safefetch implementation should not use structured exception handling

Changes: https://git.openjdk.org/jdk/pull/27074/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348862
  Stats: 172 lines in 6 files changed: 139 ins; 25 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27074/head:pull/27074

PR: https://git.openjdk.org/jdk/pull/27074

From iklam at openjdk.org  Wed Sep  3 15:26:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 3 Sep 2025 15:26:47 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing [v3]
In-Reply-To: <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
Message-ID: <yhZYrCBzJnNJHTvYi2NlHDAzPv_eP5JOoxudmc5K6go=.0d01447b-558c-403b-aaa5-5afdad0596ab@github.com>

On Wed, 3 Sep 2025 08:29:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We fail in one of our test setups with this output :
>> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
>> 
>> 
>>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] CDS is incompatible with other specified options.
>> Error occurred during initialization of VM
>> Unable to use shared archive: invalid archive
>> ];
>>  stderr: []
>>  exitValue = 1
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
>> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
>> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
>> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
>> at AOTMapTest.doTest(AOTMapTest.java:71)
>> at AOTMapTest.main(AOTMapTest.java:61)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1474)
>> 
>> 
>> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove requires

LGTM. I verified that the test runs in tiers 1-4 of our CI.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3181191898

From lmesnik at openjdk.org  Wed Sep  3 16:53:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 3 Sep 2025 16:53:42 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <xUjG82AI0YwCUCCIw56efevEt2X5vlAEO3o9Icob2LE=.a864b33a-1e67-460e-927b-5a3b6e5b5866@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27036#pullrequestreview-3181503649

From iklam at openjdk.org  Wed Sep  3 20:23:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 3 Sep 2025 20:23:46 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v2]
In-Reply-To: <4Zg07AzzEhPyY-yTvuB34OSUNSaxyePJnZKRZikW5JQ=.4eb7e85c-2194-474d-8921-c259c1b8ccd4@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <fn5j4Vanl8JKKgNsDXt_HM8Kzj_6i1cRIInjQwXiZJE=.653cbfb3-a8d4-4823-85ea-985667dbeff0@github.com>
 <6hqWp6eFz4TUIW0kJxiyGgQ8CcJpa2T_O36sT-jeYxU=.9929feaa-7561-422f-afc9-089000f33fec@github.com>
 <LpokIQiMT_QW-S7_KL9y0q6LhD0Qi6IVqn-55-OS2mQ=.a4892cea-f70b-4149-ab9a-98ec6377a052@github.com>
 <wUuHNQ-Eq5davnomMuo-H_YGZXVfyj-DTInMXUD_wNw=.418016f0-2655-4243-bd2e-dad31d4d9dd8@github.com>
 <LqtMMBDoD9LlxZzSINgKLF6ylVjMYUlS9_MptG0sE2k=.1172df57-4f9f-4f92-aa36-42f2a0e1159b@github.com>
 <4Zg07AzzEhPyY-yTvuB34OSUNSaxyePJnZKRZikW5JQ=.4eb7e85c-2194-474d-8921-c259c1b8ccd4@github.com>
Message-ID: <6BqI62eoBKfNjdC-GBRwGLVNJmfmRjzVJj0WPbgbfp8=.f551011b-6e6d-488a-bdd7-57708b0cfb85@github.com>

On Wed, 3 Sep 2025 11:24:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> My asserts say the same thing, except they comes with proofs that they are not lying.
>
> I don't like the 'else' either.

I've removed the trailing else and shuffled the asserts around as @coleenp suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27026#discussion_r2320092728

From coleenp at openjdk.org  Wed Sep  3 23:44:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 23:44:44 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v3]
In-Reply-To: <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <g1ihZU-W0rZl0OsexWaOzSaNAhhbOI3Wbva3fyAc3hA=.9f604290-cae4-4592-8df1-b0f3bd17304b@github.com>
Message-ID: <60eyRfOrdy8gwJiBKTxLQaWJNCykrr2Qu1V74fBuw8w=.0781b110-e0b9-4100-8c95-809d1597acea@github.com>

On Mon, 1 Sep 2025 07:55:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed test-only assert

This makes a lot more sense.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3182902899

From dlong at openjdk.org  Thu Sep  4 00:31:42 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 4 Sep 2025 00:31:42 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <j17HsQMH4wjiC9yAOssV1Ivx6dOMyUw_dgT-Q0KlV-c=.b7523e4d-515f-4384-adb3-cc3c9763db5c@github.com>
Message-ID: <pUL45XVf0NV3n93568ueZXcoW_l4UquTL5czT5ZXxjA=.8de29494-8151-4ac5-9c9b-4a18a163d5ed@github.com>

On Wed, 3 Sep 2025 07:12:20 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372:
> 
>> 370:         // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp));
>> 371:       }
>> 372:     }
> 
> `<arch>Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well?

Yes, it's tempting to want to clean these up, but I noticed that SA code really tries to mirror the C++ code, so I'm inclined to leave it.  Is there a Serviceability expert that would like to see this code cleaned up further?  @plummercj , what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2320526360

From ktakakuri at openjdk.org  Thu Sep  4 01:19:52 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Thu, 4 Sep 2025 01:19:52 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <AyBYtnOX-I19A-XzxvFSw3wp7mfQDpS3vx9-y2d4-Ik=.ec034a22-d6c1-47fb-9459-809076ab6e1a@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
 <hIuECle5gdWJxxZrRj3XsfIbfkknOfmtmCFfh_VA8o8=.bffc1a33-9a97-4515-9aa2-6e893ac1ca94@github.com>
 <AyBYtnOX-I19A-XzxvFSw3wp7mfQDpS3vx9-y2d4-Ik=.ec034a22-d6c1-47fb-9459-809076ab6e1a@github.com>
Message-ID: <DnUTMCuLW2vl1w3H5pTJda0LlYfAuEMqO7YnnPV2lvE=.2bf0f40f-bb0d-407c-81d6-ccc034bfbe41@github.com>

On Fri, 20 Jun 2025 09:27:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?
>
>> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?
> 
> Sure, just have some drive by comments, switching to cp437 should be okay.

@AlanBateman I know you're busy, but I'm looking forward to your review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-3251324388

From duke at openjdk.org  Thu Sep  4 04:38:52 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 4 Sep 2025 04:38:52 GMT
Subject: Integrated: 8366038: Thread::SpinRelease should use
 Atomic::release_store
In-Reply-To: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
References: <I2P-lwEBKB5VnbaUNWVr_-LGjjHI75lNYv3QK_87VKk=.3ba885b1-d0d4-494d-a8b1-cb43f71a1bec@github.com>
Message-ID: <GTb_-pJkAaKJYH_zuUr4Mli3lSHPDUJrGXarNc5ybwk=.a319a469-4bc4-4898-8967-bade37485e46@github.com>

On Mon, 1 Sep 2025 14:34:29 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> `Thread::SpinRelease()` uses an `OrderAccess::fence()` to prevent loads and stores from within the critical section to float down out of the section. A full fence is expensive and it is an overkill on most platforms. Instead, one can achieve the same effect with `Atomic::release_store()`. 
> 
> Tested in tiers 1 - 3.

This pull request has now been integrated.

Changeset: 4d1dfabc
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d1dfabcb4e94601995b07b7ecea4249ae375a04
Stats:     5 lines in 1 file changed: 0 ins; 2 del; 3 mod

8366038: Thread::SpinRelease should use Atomic::release_store

Reviewed-by: dholmes, ayang

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

PR: https://git.openjdk.org/jdk/pull/27035

From iklam at openjdk.org  Thu Sep  4 06:07:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 06:07:29 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v4]
In-Reply-To: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
Message-ID: <A4BRO0CnU3zYoUvTqdaDxoE3kTsWvuaYOdYJrPesPAo=.e6023038-cb0d-42f8-85af-19750f55a006@github.com>

> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8366498-wrong-instance-klass-cast-in-parse-super-class
 - @coleenp review - updated asserts
 - removed test-only assert
 - Simplify parse_super_klass() -> check_super_class()
 - 8366498: Wrong InstanceKlass::cast() in ClassFileParser::parse_super_class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27026/files
  - new: https://git.openjdk.org/jdk/pull/27026/files/256716fc..4422804e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27026&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27026&range=02-03

  Stats: 7048 lines in 670 files changed: 3953 ins; 1285 del; 1810 mod
  Patch: https://git.openjdk.org/jdk/pull/27026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27026/head:pull/27026

PR: https://git.openjdk.org/jdk/pull/27026

From duke at openjdk.org  Thu Sep  4 06:21:44 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Sep 2025 06:21:44 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <zh_PjkElcoThAlzWr3JY8rXSjbYJDhnhCngVTunvVdk=.972a8e68-0200-42b1-9414-b61ee0687390@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

@ArnoZeller 
Your change (at version 52d06247435a055ec8e005c59661ef867c98d7bc) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27036#issuecomment-3252092187

From azeller at openjdk.org  Thu Sep  4 06:21:45 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 4 Sep 2025 06:21:45 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <m_jZUO4yM452OHwkXDq7ToDOKWowY-kcbC48N9qSYfI=.c82789eb-fbc6-482b-a612-be644d80fac2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
 <m_jZUO4yM452OHwkXDq7ToDOKWowY-kcbC48N9qSYfI=.c82789eb-fbc6-482b-a612-be644d80fac2@github.com>
Message-ID: <TmK-S6-Cp2931aOFtIu5Xb3jHhr5NQAUXn3qnB5Po44=.16174881-1ed3-4a5e-abb0-567b24aadbd4@github.com>

On Tue, 2 Sep 2025 11:47:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one
>
> Thanks for fixing !

@MBaesken: Would you be so kind to sponsor this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27036#issuecomment-3252092379

From dholmes at openjdk.org  Thu Sep  4 06:26:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 06:26:44 GMT
Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on
 Windows aarch64
In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
Message-ID: <PSgKA-fw6agwj4Wk7e-39jZI2OL9jnxOoRZetHexNGk=.3e61ab82-41f6-4afe-8737-34d945ce5488@github.com>

On Wed, 3 Sep 2025 14:45:27 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change.
> 
> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler.
> 
> Exceptions with the DBG_PRINTEXCEPTION_C  exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code)

Just a couple of comments on the shared Windows code - I can't review the actual changes here.

Thanks

src/hotspot/os/windows/os_windows.cpp line 2670:

> 2668:   if (handle_safefetch(exception_code, pc, (void*)exceptionInfo->ContextRecord)) {
> 2669:     return EXCEPTION_CONTINUE_EXECUTION;
> 2670:   }

Could you merge with the existing ARM64 section so we only have two distinct code chunks: one for X64 and one for aarch64. Thanks

src/hotspot/share/runtime/safefetch.hpp line 35:

> 33: 
> 34: #if defined(_WIN32) && !defined(_M_ARM64)
> 35:   // Windows uses Structured Exception Handling

Suggestion:

#if defined(_WIN32) && !defined(_M_ARM64)
  // Windows x86_64 uses Structured Exception Handling

And update the main comment in safefetch_windows.hpp to say the same.

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

PR Review: https://git.openjdk.org/jdk/pull/27074#pullrequestreview-3183597041
PR Review Comment: https://git.openjdk.org/jdk/pull/27074#discussion_r2320946522
PR Review Comment: https://git.openjdk.org/jdk/pull/27074#discussion_r2320969695

From dholmes at openjdk.org  Thu Sep  4 06:28:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 06:28:46 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v6]
In-Reply-To: <qwpr6h_9Yk9a-iK5QtP8091W7-MiUeTyEIeXxyOjXLI=.ba22b0b3-b99f-4942-9fe0-be62ef71d920@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <qwpr6h_9Yk9a-iK5QtP8091W7-MiUeTyEIeXxyOjXLI=.ba22b0b3-b99f-4942-9fe0-be62ef71d920@github.com>
Message-ID: <8jfKhDGOanHjx3qZbEbnIi3p0Fo1EZ8Aa2pvsR8J294=.055da8f4-e2b3-4911-8047-b5a08a8bfba2@github.com>

On Wed, 3 Sep 2025 08:08:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   message fix

LGTM. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3183638995

From mbaesken at openjdk.org  Thu Sep  4 07:05:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Sep 2025 07:05:51 GMT
Subject: RFR: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <clMt0w9AP297-vTybRqpdPV528DLMbrwWSaotnSEjUc=.be20d379-356a-4a4b-8e4b-2e07417302d4@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

Sure !

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

PR Comment: https://git.openjdk.org/jdk/pull/27036#issuecomment-3252208958

From azeller at openjdk.org  Thu Sep  4 07:05:51 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 4 Sep 2025 07:05:51 GMT
Subject: Integrated: 8366558: Gtests leave /tmp/cgroups-test* files
In-Reply-To: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
References: <4rfhVeJNH_Me10ll0ogNoio-Dw1A_adZj5JTGOZfETk=.de1ec842-51f9-4624-9308-bb46239591c2@github.com>
Message-ID: <oSwVsLYGpbY5RzfnMCuGygUWNjUgMRGz2P5gIaRXjU4=.fe979eb6-3081-4e56-919d-96a06a9fb7d7@github.com>

On Mon, 1 Sep 2025 15:44:37 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The gtests leave two files on Linux in the tmp directory. This change will move the cleanup code to the end in one sub test and add a missing cleanup code in another one

This pull request has now been integrated.

Changeset: 49fd6a0c
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49fd6a0cb4ddabaa865155bbfd4290077b7d13ea
Stats:     5 lines in 1 file changed: 4 ins; 1 del; 0 mod

8366558: Gtests leave /tmp/cgroups-test* files

Reviewed-by: mbaesken, stuefe, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/27036

From mbaesken at openjdk.org  Thu Sep  4 07:15:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Sep 2025 07:15:44 GMT
Subject: RFR: 8366420: AOTMapTest fails when jsa is missing [v3]
In-Reply-To: <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
Message-ID: <d9sGUoE4Thr9g_LV0FqVToriUpyC6uzNtfvbKlXwIp4=.92832ac1-f653-46b3-ae94-706e1e9ea973@github.com>

On Wed, 3 Sep 2025 08:29:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We fail in one of our test setups with this output :
>> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
>> 
>> 
>>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] CDS is incompatible with other specified options.
>> Error occurred during initialization of VM
>> Unable to use shared archive: invalid archive
>> ];
>>  stderr: []
>>  exitValue = 1
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
>> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
>> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
>> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
>> at AOTMapTest.doTest(AOTMapTest.java:71)
>> at AOTMapTest.main(AOTMapTest.java:61)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1474)
>> 
>> 
>> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove requires

Thanks for the review and thanks for checking your CI tests !

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

PR Comment: https://git.openjdk.org/jdk/pull/27001#issuecomment-3252247863

From dholmes at openjdk.org  Thu Sep  4 07:23:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Sep 2025 07:23:45 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v4]
In-Reply-To: <A4BRO0CnU3zYoUvTqdaDxoE3kTsWvuaYOdYJrPesPAo=.e6023038-cb0d-42f8-85af-19750f55a006@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <A4BRO0CnU3zYoUvTqdaDxoE3kTsWvuaYOdYJrPesPAo=.e6023038-cb0d-42f8-85af-19750f55a006@github.com>
Message-ID: <FkCLGV-Jb0NbiKM8tjjCt11Obon2JpEiJXk_azx2IvA=.4e421970-b51b-420d-806d-f8f2d2e4bc21@github.com>

On Thu, 4 Sep 2025 06:07:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8366498-wrong-instance-klass-cast-in-parse-super-class
>  - @coleenp review - updated asserts
>  - removed test-only assert
>  - Simplify parse_super_klass() -> check_super_class()
>  - 8366498: Wrong InstanceKlass::cast() in ClassFileParser::parse_super_class

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27026#pullrequestreview-3183806985

From azeller at openjdk.org  Thu Sep  4 07:58:43 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 4 Sep 2025 07:58:43 GMT
Subject: RFR: 8366420: AOTMapTest fails when default jsa is missing from
 JDK [v3]
In-Reply-To: <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
 <7Cpg0FFEYoyVxEin0whvbtkG3mRDCj8VoueLKxoRADQ=.4c78b509-7bbb-42f1-94b3-6a8ed891ca5e@github.com>
Message-ID: <IhdIcRkrL6tsqx6GTrlkIlyOyUyuia5K889gk_VrYjI=.2b1470c5-3977-49bb-8f91-773804e45fce@github.com>

On Wed, 3 Sep 2025 08:29:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We fail in one of our test setups with this output :
>> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
>> 
>> 
>>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
>> [0.003s][error][cds] CDS is incompatible with other specified options.
>> Error occurred during initialization of VM
>> Unable to use shared archive: invalid archive
>> ];
>>  stderr: []
>>  exitValue = 1
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
>> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
>> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
>> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
>> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
>> at AOTMapTest.doTest(AOTMapTest.java:71)
>> at AOTMapTest.main(AOTMapTest.java:61)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1474)
>> 
>> 
>> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove requires

Looks reasonable to me.

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

Marked as reviewed by azeller (Author).

PR Review: https://git.openjdk.org/jdk/pull/27001#pullrequestreview-3183916742

From mbaesken at openjdk.org  Thu Sep  4 08:03:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Sep 2025 08:03:48 GMT
Subject: Integrated: 8366420: AOTMapTest fails when default jsa is missing from
 JDK
In-Reply-To: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
References: <lNWjshdsRvOaNqHJp-zR-fVNBV7JL263IP2GOuSsmDw=.e866422e-b7ab-437d-9974-f4013dc9ac54@github.com>
Message-ID: <Mg_F2O54LXNF8KWc8w-l-wPeTouqsBZo1iJGwMV3eQI=.fc86e306-8924-4cbd-ba91-094a71b2f68a@github.com>

On Fri, 29 Aug 2025 07:58:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We fail in one of our test setups with this output :
> runtime/cds/appcds/aotCache/AOTMapTest_dynamic
> 
> 
>  stdout: [[0.003s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
> [0.003s][error][cds] Specified shared archive file not found (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] Not a valid shared archive file (AOTMapTestApp.dynamic.jsa)
> [0.003s][error][cds] CDS is incompatible with other specified options.
> Error occurred during initialization of VM
> Unable to use shared archive: invalid archive
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522)
> at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:217)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:426)
> at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:393)
> at jdk.test.lib.cds.CDSAppTester.runDynamicWorkflow(CDSAppTester.java:464)
> at jdk.test.lib.cds.CDSAppTester.run(CDSAppTester.java:445)
> at AOTMapTest.doTest(AOTMapTest.java:71)
> at AOTMapTest.main(AOTMapTest.java:61)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> 
> This test setup is a bit special because it contains only one jsa cds archive (the one for compressed object headers).  So the  'classes.jsa' is missing .

This pull request has now been integrated.

Changeset: ab9f70dd
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab9f70dd5acd73744e3d82e9884985904f280c26
Stats:     22 lines in 2 files changed: 0 ins; 16 del; 6 mod

8366420: AOTMapTest fails when default jsa is missing from JDK

Reviewed-by: iklam, azeller

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

PR: https://git.openjdk.org/jdk/pull/27001

From duke at openjdk.org  Thu Sep  4 09:40:24 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 4 Sep 2025 09:40:24 GMT
Subject: RFR: 8366864: Sort os/linux includes
Message-ID: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>

This PR sorts the includes in hotspot/cpu/linux using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

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

Commit messages:
 - add dir
 - sort

Changes: https://git.openjdk.org/jdk/pull/27088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366864
  Stats: 115 lines in 14 files changed: 52 ins; 50 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27088/head:pull/27088

PR: https://git.openjdk.org/jdk/pull/27088

From cnorrbin at openjdk.org  Thu Sep  4 09:50:52 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Sep 2025 09:50:52 GMT
Subject: RFR: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks [v4]
In-Reply-To: <SYGF5A7yQYsBkplGSJTKxGGAivSkIANwAdt33MIzMvo=.9d5984b2-1eae-4fe3-a5d0-fb7d02d4984d@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
 <SYGF5A7yQYsBkplGSJTKxGGAivSkIANwAdt33MIzMvo=.9d5984b2-1eae-4fe3-a5d0-fb7d02d4984d@github.com>
Message-ID: <bRBFTX_0zrMxv8BL_PA3gzXLUxZiX5v4RL6TVXYyiFg=.578da96a-d811-4951-aaa6-8500041b3b5c@github.com>

On Mon, 1 Sep 2025 13:40:28 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current red-black tree can be made safer, and its inspection capabilities improved.
>> 
>> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
>> 
>> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
>> 
>> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
>> 
>> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
>> 
>> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
>> 
>> Testing:
>> - Oracle tiers 1-3
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   johan feedback

Thank you everyone for reviewing! Let's push this!

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

PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3252856275

From cnorrbin at openjdk.org  Thu Sep  4 09:50:53 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Sep 2025 09:50:53 GMT
Subject: Integrated: 8366238: Improve RBTree API with stricter comparator
 semantics and pluggable validation/printing hooks
In-Reply-To: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
References: <xBBv_Un-GHPOs_Ri3_1aop840xjcQpScyPXOJZ31kjo=.57eec1fc-d4ce-4b05-bff5-b9851f496503@github.com>
Message-ID: <j6ywWWwS_-M_E6Zg29PPR8rL_PbZCE_HThIVR0mAooc=.b385c365-98d8-4943-9990-3114604cfe5e@github.com>

On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The current red-black tree can be made safer, and its inspection capabilities improved.
> 
> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading.
> 
> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions.
> 
> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses.
> 
> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur.
> 
> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality.
> 
> Testing:
> - Oracle tiers 1-3

This pull request has now been integrated.

Changeset: 53d4e928
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53d4e928ef2851f3e16d1d200b5c3fb036e15e00
Stats:     267 lines in 7 files changed: 167 ins; 9 del; 91 mod

8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks

Reviewed-by: jsjolen, ayang

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

PR: https://git.openjdk.org/jdk/pull/26981

From azafari at openjdk.org  Thu Sep  4 09:57:48 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 4 Sep 2025 09:57:48 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12]
In-Reply-To: <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
Message-ID: <XvSqckNXfd9KI3Y8UEO4KldYuIqIvDftR_pL6UryzM0=.f1efac1d-2bde-4f6c-ac55-ecad0d26fe65@github.com>

On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline
>  - Rename to _vma_allocations
>  - After a lot of casting
>  - Yup
>  - Some more ugly casts
>  - Aha, _root is typed as an IntrusiveRBNode
>  - Aha, missing include
>  - Wait, the VMATree is wrong?
>  - Rename
>  - It's const
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b

All good! Thanks!

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

Marked as reviewed by azafari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3184365123

From jsjolen at openjdk.org  Thu Sep  4 09:57:48 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 4 Sep 2025 09:57:48 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12]
In-Reply-To: <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
Message-ID: <kMr0zb_Uqz27hLQszmddslvz99or7XEzeZ05Nok_OYE=.c4173138-5ab8-4e6f-bcf2-834c948c1bfc@github.com>

On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline
>  - Rename to _vma_allocations
>  - After a lot of casting
>  - Yup
>  - Some more ugly casts
>  - Aha, _root is typed as an IntrusiveRBNode
>  - Aha, missing include
>  - Wait, the VMATree is wrong?
>  - Rename
>  - It's const
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b

Mach5 passes tier1 and tier2.

@caspernorrbin , @afshin-zafari , @Arraying , could you review this again?

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

PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3252209567

From cnorrbin at openjdk.org  Thu Sep  4 09:57:49 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Sep 2025 09:57:49 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12]
In-Reply-To: <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <NxmgT8cz6gv1Z2-HBw5vf0h0-RUsiSrDgEP1WAhH8Dg=.f1041790-d5cf-410b-96d8-b7cf6f2229fb@github.com>
Message-ID: <NVfbyeTvFVtO9YUZsEqvHp49dJreiW4rjK8JzGNX7sI=.f2554fa2-9b9a-46d5-a34b-f9161fc2327b@github.com>

On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline
>  - Rename to _vma_allocations
>  - After a lot of casting
>  - Yup
>  - Some more ugly casts
>  - Aha, _root is typed as an IntrusiveRBNode
>  - Aha, missing include
>  - Wait, the VMATree is wrong?
>  - Rename
>  - It's const
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b

src/hotspot/share/utilities/rbTree.hpp line 457:

> 455:   ~RBTree() { remove_all(); }
> 456: 
> 457:   bool copy_into(RBTree& other) const {

Could you move this function into `rbTree.inline.hpp` instead? It's a bit too big to fit here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2321477007

From ayang at openjdk.org  Thu Sep  4 11:31:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Sep 2025 11:31:45 GMT
Subject: RFR: 8366864: Sort os/linux includes
In-Reply-To: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
References: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
Message-ID: <RKEO9l2uHhTIhT7kkBiDIedomswFcTBERJ5Ci462ffw=.73230e72-7005-4d7e-a93f-6f758d266a53@github.com>

On Thu, 4 Sep 2025 09:28:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/cpu/linux using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27088#pullrequestreview-3184722888

From jsjolen at openjdk.org  Thu Sep  4 11:43:24 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 4 Sep 2025 11:43:24 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v13]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <In2u7JwMVbOZTOY2RvjqiOzz0HNUeRp6km7z0VBMlyI=.f76adbe5-85d6-4a33-b74f-c89bd3abd6fd@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Move into rbTree.inline.hpp file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/82df750b..615598e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=11-12

  Stats: 96 lines in 2 files changed: 49 ins; 46 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From jsjolen at openjdk.org  Thu Sep  4 11:46:26 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 4 Sep 2025 11:46:26 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14]
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <e5tpytmOK0po-x06p0EoeruRxvTlnVeozbNp0-15550=.ec1abfed-d222-4a74-8669-bb38e2300663@github.com>

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Missed const-ness

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27003/files
  - new: https://git.openjdk.org/jdk/pull/27003/files/615598e6..3bfe8593

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003

PR: https://git.openjdk.org/jdk/pull/27003

From cnorrbin at openjdk.org  Thu Sep  4 13:03:48 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 4 Sep 2025 13:03:48 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14]
In-Reply-To: <e5tpytmOK0po-x06p0EoeruRxvTlnVeozbNp0-15550=.ec1abfed-d222-4a74-8669-bb38e2300663@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <e5tpytmOK0po-x06p0EoeruRxvTlnVeozbNp0-15550=.ec1abfed-d222-4a74-8669-bb38e2300663@github.com>
Message-ID: <t_bf1dsIxoWI0kT6s5WKpUHcrD4-7v2mlFlfpNPd3lw=.ea586bf2-7617-46e2-bd57-0d7e087849ce@github.com>

On Thu, 4 Sep 2025 11:46:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed const-ness

Looks good!

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

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3185157530

From phubner at openjdk.org  Thu Sep  4 13:12:35 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 4 Sep 2025 13:12:35 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v2]
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Incorporate reviewer feedback.
 - Merge branch 'master' into JDK-8364103
 - Refactor stack trace printing to use stringStream.

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

Changes: https://git.openjdk.org/jdk/pull/26894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26894&range=01
  Stats: 32 lines in 1 file changed: 5 ins; 15 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26894/head:pull/26894

PR: https://git.openjdk.org/jdk/pull/26894

From phubner at openjdk.org  Thu Sep  4 13:12:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 4 Sep 2025 13:12:36 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v2]
In-Reply-To: <j_adD4_DJO0OhxPzQCW_cT-fc6TXlHGp_LRElTvUFIA=.ba5ee74f-f3c0-4d50-a73b-c83042e99341@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <j_adD4_DJO0OhxPzQCW_cT-fc6TXlHGp_LRElTvUFIA=.ba5ee74f-f3c0-4d50-a73b-c83042e99341@github.com>
Message-ID: <bVuGetVS5OwXw32HkPnPtJeEsEICBtFLf4C6AbROVaI=.68703d97-be94-4046-898c-40c68dfcf7a7@github.com>

On Fri, 22 Aug 2025 18:24:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Incorporate reviewer feedback.
>>  - Merge branch 'master' into JDK-8364103
>>  - Refactor stack trace printing to use stringStream.
>
> Why are we printing to a buffer first?
> 
> Originally this function was `java_lang_Throwable::print_stack_element_to_buffer()` and returns a buffer. Hence the anachronistic comment "// Print stack trace element to resource allocated buffer"  which is no longer correct.
> 
> I can't find any information from the history of this file:
> 
> https://github.com/openjdk/jdk/blame/68f3dd76c92ce3b0219ac2cc346718dd865645d9/hotspot/src/share/vm/classfile/javaClasses.cpp#L1161
> 
> I am guessing the reason is to avoid interleaving with other threads. I think the above comment should be updated to reflect this.

@iklam thanks for the feedback, I've addressed your remarks. Thanks also @kimbarrett and @dholmes-ora for notifying me about your change, I've superseded those with the stringBuilder. 

I hope I've addressed the comments satisfactorily, if not please do let me know and I'll do another iteration of changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26894#issuecomment-3253639901

From stefank at openjdk.org  Thu Sep  4 13:34:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Sep 2025 13:34:51 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v6]
In-Reply-To: <qwpr6h_9Yk9a-iK5QtP8091W7-MiUeTyEIeXxyOjXLI=.ba22b0b3-b99f-4942-9fe0-be62ef71d920@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <qwpr6h_9Yk9a-iK5QtP8091W7-MiUeTyEIeXxyOjXLI=.ba22b0b3-b99f-4942-9fe0-be62ef71d920@github.com>
Message-ID: <1ehRD5x6szUhZp2OXJc0vxvlM05H7ANJFnl2IwKI09o=.4713c694-e191-41a3-8cfd-883d67a2af72@github.com>

On Wed, 3 Sep 2025 08:08:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   message fix

I still find it weird that the error message says "percentage":

jio_fprintf(defaultStream::error_stream(),
            "Bad max heap free percentage size: %s\n",
            option->optionString);


The new code also mixes the style w.r.t. using redundant `else`s vs early returns. Could you straighten up the code so that all error checking is at the same indentation level?:


      if (*err != '\0' || *tail == '\0') {
        jio_fprintf(defaultStream::error_stream(),
                    "Bad max heap free ratio: %s\n",
                    option->optionString);
        return JNI_EINVAL;
      }
      if (dmaxf < 0.0 || dmaxf > 1.0) {
        jio_fprintf(defaultStream::error_stream(),
                    "-Xmaxf value (%s) is outside the allowed range [ 0.0 ... 1.0 ]\n",
                    option->optionString);
        return JNI_EINVAL;
      }
      if (MinHeapFreeRatio > (uintx)(dmaxf * 100)) {
        jio_fprintf(defaultStream::error_stream(),
                    "-Xmaxf value (%s) must be greater than or equal to the implicit -Xminf value (%3.2lf)\n",
                    tail, MinHeapFreeRatio / 100.0);
        return JNI_EINVAL;
      }
      if (FLAG_SET_CMDLINE(MaxHeapFreeRatio, (uintx)(dmaxf * 100)) != JVMFlag::SUCCESS) {
          return JNI_EINVAL;
      }

This could be extracted into a local constant:

(uintx)(dmaxf * 100)

I don't think there should be a 3 here:

(%3.2lf)

In another PR I saw that the usage of `%lf` instead of `%f` was questioned. Should we be using `%lf` here?

      if (FLAG_SET_CMDLINE(MaxHeapFreeRatio, (uintx)(dmaxf * 100)) != JVMFlag::SUCCESS) {
          return JNI_EINVAL;
      }

There's an incorrect indentation at the return statement.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3185325686

From sjohanss at openjdk.org  Thu Sep  4 14:24:59 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 4 Sep 2025 14:24:59 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
Message-ID: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>

Please review this enhancement to the smaps parser and printer.

**Summary**
While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.

It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.

For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.

**Testing**
* Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

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

Commit messages:
 - Fix test
 - 8366780: Enhance ProcSmapsParser and Printer to handle THPeligible field

Changes: https://git.openjdk.org/jdk/pull/27098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366780
  Stats: 20 lines in 4 files changed: 9 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27098/head:pull/27098

PR: https://git.openjdk.org/jdk/pull/27098

From duke at openjdk.org  Thu Sep  4 15:09:09 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Thu, 4 Sep 2025 15:09:09 GMT
Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on
 Windows aarch64 [v2]
In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
Message-ID: <3zxXHRrQ-UeqSWVRvR7teowA4JICAEz_5SKLZ2ZB5LA=.078f3add-0b5c-4ad7-9514-3e7fb026572e@github.com>

> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change.
> 
> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler.
> 
> Exceptions with the DBG_PRINTEXCEPTION_C  exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code)

Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:

  Clarify that SEH is only used on Windows x86_64
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27074/files
  - new: https://git.openjdk.org/jdk/pull/27074/files/b66170a4..b35b47fb

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27074/head:pull/27074

PR: https://git.openjdk.org/jdk/pull/27074

From iklam at openjdk.org  Thu Sep  4 15:43:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 15:43:44 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v2]
In-Reply-To: <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>
Message-ID: <RIn_gZGHhqSr6fvNTbHi_Gv-EXdn9HZGkJn6fT94od0=.991d61ec-a0d2-41ad-9c4c-dfee4ec83295@github.com>

On Thu, 4 Sep 2025 13:12:35 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Incorporate reviewer feedback.
>  - Merge branch 'master' into JDK-8364103
>  - Refactor stack trace printing to use stringStream.

LGTM.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3185929582

From iklam at openjdk.org  Thu Sep  4 16:22:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 16:22:56 GMT
Subject: RFR: 8366498: Simplify ClassFileParser::parse_super_class [v4]
In-Reply-To: <FkCLGV-Jb0NbiKM8tjjCt11Obon2JpEiJXk_azx2IvA=.4e421970-b51b-420d-806d-f8f2d2e4bc21@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
 <A4BRO0CnU3zYoUvTqdaDxoE3kTsWvuaYOdYJrPesPAo=.e6023038-cb0d-42f8-85af-19750f55a006@github.com>
 <FkCLGV-Jb0NbiKM8tjjCt11Obon2JpEiJXk_azx2IvA=.4e421970-b51b-420d-806d-f8f2d2e4bc21@github.com>
Message-ID: <4JbevNQ8mt1HTKVh0M9Z3GWI2RBPiFOTbQQPdX7CVKk=.10841f0f-85f2-4fa8-bd57-f6905b461e29@github.com>

On Thu, 4 Sep 2025 07:21:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8366498-wrong-instance-klass-cast-in-parse-super-class
>>  - @coleenp review - updated asserts
>>  - removed test-only assert
>>  - Simplify parse_super_klass() -> check_super_class()
>>  - 8366498: Wrong InstanceKlass::cast() in ClassFileParser::parse_super_class
>
> Looks good. Thanks

Thanks @dholmes-ora @coleenp for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27026#issuecomment-3254482367

From iklam at openjdk.org  Thu Sep  4 16:22:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 4 Sep 2025 16:22:56 GMT
Subject: Integrated: 8366498: Simplify ClassFileParser::parse_super_class
In-Reply-To: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
References: <4gpAbWr-m7WxTmzO6uds64juWVEiGBawmoY94Tw0xSE=.7dcae9ae-6378-4f6b-b2ef-1a31a9b7379b@github.com>
Message-ID: <GspsLMxy_WANCLnolpDKcXLoMvw62s5v1--OlLcdgrU=.a0bd4108-d785-4e0a-9744-f13e76bd06ba@github.com>

On Mon, 1 Sep 2025 05:19:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The if `cp->resolved_klass_at()` is never true called because we are very early in class file parsing, so no klass CP entries have been resolved at this point.

This pull request has now been integrated.

Changeset: 79a1a98c
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79a1a98cabb579a5de504144abacb386486fba7e
Stats:     33 lines in 2 files changed: 4 ins; 10 del; 19 mod

8366498: Simplify ClassFileParser::parse_super_class

Reviewed-by: dholmes, coleenp

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

PR: https://git.openjdk.org/jdk/pull/27026

From kbarrett at openjdk.org  Thu Sep  4 17:52:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Sep 2025 17:52:45 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v2]
In-Reply-To: <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>
Message-ID: <v7yPM9GzgnsxyXkmearyXHPLF0vSJeF4MZgkZpDXy9k=.e1d0c818-6a8b-4d83-b428-9a5451a433c4@github.com>

On Thu, 4 Sep 2025 13:12:35 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Incorporate reviewer feedback.
>  - Merge branch 'master' into JDK-8364103
>  - Refactor stack trace printing to use stringStream.

Looks okay as is, but there is some optional tidying up that could be done.

src/hotspot/share/classfile/javaClasses.cpp line 2615:

> 2613:   }
> 2614: 
> 2615:   stringStream ss;

Consider moving the stringStream declaration up near the front of the function, and moving the print of
`klass_name` and `method_name` earlier, to just after they are set up. And consider moving the setup
of `source_file_name` down closer to where it's used. The early setups before printing were needed in
the old code as part of calculating the buffer length. But that's no longer a concern.

src/hotspot/share/classfile/javaClasses.cpp line 2648:

> 2646:       nmethod* nm = method->code();
> 2647:       if (WizardMode && nm != nullptr) {
> 2648:         ss.print("(nmethod " INTPTR_FORMAT ")", (intptr_t)nm);

pre-existing: Usual practice is to use `p2i(nm)` rather than a cast.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3186410195
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2322968092
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2322951743

From ayang at openjdk.org  Thu Sep  4 17:59:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 4 Sep 2025 17:59:41 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>

On Thu, 4 Sep 2025 14:19:06 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

src/hotspot/os/linux/procMapsParser.hpp line 52:

> 50:   size_t anonhugepages;
> 51:   size_t swap;
> 52:   size_t thpeligible;

Why `size`? Its name sounds like `bool`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2322987857

From matsaave at openjdk.org  Thu Sep  4 18:07:53 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 4 Sep 2025 18:07:53 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
Message-ID: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>

The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.

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

Commit messages:
 - Removed unused methods and declarations
 - 8364660: ClassVerifier::ends_in_athrow() should be removed

Changes: https://git.openjdk.org/jdk/pull/27107/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364660
  Stats: 250 lines in 3 files changed: 0 ins; 250 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27107/head:pull/27107

PR: https://git.openjdk.org/jdk/pull/27107

From matsaave at openjdk.org  Thu Sep  4 18:24:57 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 4 Sep 2025 18:24:57 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
References: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
Message-ID: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>

> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fixed copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27107/files
  - new: https://git.openjdk.org/jdk/pull/27107/files/57003c7f..7b54a9f6

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27107/head:pull/27107

PR: https://git.openjdk.org/jdk/pull/27107

From liach at openjdk.org  Thu Sep  4 23:22:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 23:22:40 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
References: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
 <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
Message-ID: <BAgR3pBNYIdx55xMrExkaAWimapdBJx_2nHNCY78czQ=.ff2bb11b-17a9-4af6-a7c3-20529ae0a096@github.com>

On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright

Looks reasonable, and ClassFile API changes look good.

In JVMS 24 [4.10.1.9.invokespecial](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.10.1.9.invokespecial):

> In the special case of initializing the current object (that is, when invoking <init> for type uninitializedThis), the original frame typically holds an uninitialized object in local variable 0 and has flag flagThisUninit. Normal termination of invokespecial initializes the uninitialized object and turns off the flagThisUninit flag. But if the invokespecial invocation throws an exception, the exception frame contains the broken object (with type top) and the flagThisUninit flag (the old flag). There is no way to perform a return instruction given that type state, so the handler would have to throw another exception (or loop forever). In fact, it's not even possible to express a handler with that type state, because there is no way for a stack frame, as expressed by the StackMapTable attribute ([?4.7.4](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.7.4)), to carry flagThisUninit without any accompanying use of type uninitializedThis.

Justifies this change.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27107#pullrequestreview-3187515624

From dlong at openjdk.org  Fri Sep  5 00:28:20 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 5 Sep 2025 00:28:20 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
References: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
 <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
Message-ID: <RhFBM5Qie5K2piALlA76JMSnOeDLyRmCUNf4sxal2p4=.46aa3600-5675-40c3-b5b0-113c6fad00f1@github.com>

On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27107#pullrequestreview-3187604303

From sjohanss at openjdk.org  Fri Sep  5 06:26:11 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 06:26:11 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field
In-Reply-To: <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
Message-ID: <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>

On Thu, 4 Sep 2025 17:56:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> src/hotspot/os/linux/procMapsParser.hpp line 52:
> 
>> 50:   size_t anonhugepages;
>> 51:   size_t swap;
>> 52:   size_t thpeligible;
> 
> Why `size`? Its name sounds like `bool`?

Yes, it works like a `bool` but I represented it as a number to simply do the parsing similar to the other fields, but I guess I could handle it more like how `VmFlags` are handled.

The the parsing would then look like this, would you prefer that:

if (strncmp(_line, "THPeligible:", 12) == 0) {
  out.thpeligible = ::strstr(_line + 12, "1") != nullptr;
  return;
}


I think I would =)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2324211968

From duke at openjdk.org  Fri Sep  5 06:51:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 5 Sep 2025 06:51:09 GMT
Subject: RFR: 8366864: Sort os/linux includes
In-Reply-To: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
References: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
Message-ID: <9uLbauL9cRSO6F9CSr0Wq3zJ4BckULcEuyxGmlGNasg=.91ce8b0d-aa51-4e80-971d-b5c3972ddb73@github.com>

On Thu, 4 Sep 2025 09:28:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/cpu/linux using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

@fandreuz 
Your change (at version 27aee09ff06489e6030636543390c41373a80d39) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27088#issuecomment-3257259418

From sjohanss at openjdk.org  Fri Sep  5 07:02:46 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 07:02:46 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/197bbdb7..521afbad

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

  Stats: 26 lines in 3 files changed: 7 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27098/head:pull/27098

PR: https://git.openjdk.org/jdk/pull/27098

From sjohanss at openjdk.org  Fri Sep  5 07:02:47 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 07:02:47 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <1s0wZ3_PidYtoqUAQ1OrKvCAX8sZGH-yjhpS-OYPjlo=.18a381d1-9158-46af-bf33-d32a509005b8@github.com>
 <q9qgQpW37prTK8Z0AUHpsMXP6_QUzZgYKeolm7TTyOU=.dba27c26-ccbf-45b1-a274-64fb0c81cdaf@github.com>
Message-ID: <1B5C3k7B5EkGH0Rso9E3G1cQHb-izDTGEYlggzCQ4mo=.ec94952b-7254-4c8e-ada9-c797dff57f7e@github.com>

On Fri, 5 Sep 2025 06:23:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/os/linux/procMapsParser.hpp line 52:
>> 
>>> 50:   size_t anonhugepages;
>>> 51:   size_t swap;
>>> 52:   size_t thpeligible;
>> 
>> Why `size`? Its name sounds like `bool`?
>
> Yes, it works like a `bool` but I represented it as a number to simply do the parsing similar to the other fields, but I guess I could handle it more like how `VmFlags` are handled.
> 
> The the parsing would then look like this, would you prefer that:
> 
> if (strncmp(_line, "THPeligible:", 12) == 0) {
>   out.thpeligible = ::strstr(_line + 12, "1") != nullptr;
>   return;
> }
> 
> 
> I think I would =)

Or actually make use of the unused ?nt` in the code, which I now when looking at the old review realize was used for the THPeligible field (but that parsing was then later removed). 

I'll push a change which does: 

  // scan THPeligible into a bool
  int thpel = 0;
  if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {
    out.thpeligible = (thpel == 1);
    return;
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2324269607

From sjohanss at openjdk.org  Fri Sep  5 08:33:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 08:33:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
Message-ID: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>

> Please review this enhancement to the smaps parser and printer.
> 
> **Summary**
> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
> 
> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
> 
> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
> 
> **Testing**
> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  Offline comments and discussion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/521afbad..d9aa3c29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27098&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27098&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27098/head:pull/27098

PR: https://git.openjdk.org/jdk/pull/27098

From sjohanss at openjdk.org  Fri Sep  5 08:33:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 5 Sep 2025 08:33:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v2]
In-Reply-To: <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <64TF7UNv_hZh6HPKn6IjHkxAqe3SidxP8VUqTNb3VyI=.82fdd9a0-bd9b-41e9-8e8a-34cba382b47a@github.com>
Message-ID: <GQYPV9BGSlRF6N7b-lM1APZjDyrkQKyw3T2SQL3MJ18=.88f1af95-fe52-459f-ae11-2c1adb861f32@github.com>

On Fri, 5 Sep 2025 07:02:46 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

After some offline discussion we've decided to not filter away `thpel` for mappings with the `thpad` tag set, because a mapping can have the `thpad` tag but not bet THPeligible. For example if you would `madvise` a too small region. So showing both tags have a value. 

Also changing the order of the THP tags to be in order of significance:
thp - mapping backed by at least one huge page
thpel - OS marked mapping as eligible for huge pages
thpad - JVM requested mapping to be backed by huge pages

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3257516929

From azafari at openjdk.org  Fri Sep  5 09:02:27 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 5 Sep 2025 09:02:27 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v7]
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <RtuH3bMLW-fRnzXj9oXB3aSmkmoB0EisYN0fz_l11h0=.73d30ea8-b798-410b-be3d-21b2aa5c70e4@github.com>

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  review comments applied.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26859/files
  - new: https://git.openjdk.org/jdk/pull/26859/files/0b532758..041452e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26859&range=05-06

  Stats: 36 lines in 2 files changed: 0 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/26859.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26859/head:pull/26859

PR: https://git.openjdk.org/jdk/pull/26859

From ayang at openjdk.org  Fri Sep  5 09:27:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 5 Sep 2025 09:27:11 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
Message-ID: <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>

On Fri, 5 Sep 2025 08:33:38 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to the smaps parser and printer.
>> 
>> **Summary**
>> While working on [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434) one idea for a test to verify if the heap CAN be backed by transparent huge pages (THP) was to use PrintMemoryMapAtExit and look at the tags printed for JAVAHEAP.
>> 
>> It turns out this worked in most cases but on systems where the THP mode is configured as 'always' but there are no huge pages available for use, the JAVAHEAP line will not show any indication that it can be backed by huge pages.
>> 
>> For this to be possible we need to parse the field THPeligible as well and include this information in the printouts. With this change we now parse the THPeligible field and tag mapping that are THP eligible with `thpel`. We skip this tag for mappings that are tagged with `thpad` (madvised with MADV_HUGEPAGE) to avoid too much THP info on one mapping.
>> 
>> **Testing**
>> * Mach5 testing with the existing test showed a need to update the regex for verifying Metaspace and the fix have been tested manually locally as well as in Mach5.
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline comments and discussion

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3188630381

From duke at openjdk.org  Fri Sep  5 09:59:46 2025
From: duke at openjdk.org (mazhen)
Date: Fri, 5 Sep 2025 09:59:46 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
Message-ID: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>

#### Summary

This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.

#### Problem

The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.

*   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
*   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.

#### Solution

The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.

This change makes the test's logic robust and its behavior consistent across different environments.

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

Commit messages:
 - 8366787: runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms

Changes: https://git.openjdk.org/jdk/pull/27114/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366787
  Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27114/head:pull/27114

PR: https://git.openjdk.org/jdk/pull/27114

From duke at openjdk.org  Fri Sep  5 10:07:13 2025
From: duke at openjdk.org (mazhen)
Date: Fri, 5 Sep 2025 10:07:13 GMT
Subject: RFR: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
 <WaJAIzDBInPjIn0fHIqYft8IQOP0SaVPiTDD6soFSgQ=.a2ba745a-f767-4b24-b5c3-d46e8264dd17@github.com>
Message-ID: <0zHUgs7hfpVKK-FIQiWzANzxjn5MxMXm_j-6VSUyPSs=.b97d8603-ae4b-440a-89f0-08c158acd01c@github.com>

On Mon, 1 Sep 2025 04:32:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
>> 
>> **Summary of the Problem:**
>> 
>> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
>> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
>> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
>> 
>> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
>> 
>> **Test Objective Analysis:**
>> 
>> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
>> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
>> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
>> 
>> **How the Original Implementation Deviated from the Test Intent:**
>> 
>> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
>> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>>  ...
>
> I would suggest filing a new bug for the CentOS hang and create a new PR of the change here, with that new bug ID.

Hi @dholmes-ora and @sendaoYan,

Thank you so much, @sendaoYan, for creating the JBS issue for me! I really appreciate your help in moving this forward.

As suggested by @dholmes-ora, I am now closing this PR because it was linked to the incorrect JBS issue.

I have followed the advice and taken the following steps:
1.  A new JBS issue has been created to correctly track the hang on CentOS: **JDK-8366787**.
2.  I have created a new Pull Request containing the same fix, now linked to this new, correct issue.

The new PR is available here: [#27114](https://github.com/openjdk/jdk/pull/27114)

Thank you again for all your support in getting this on the right track. All future discussion should please continue on the new PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25689#issuecomment-3257797404

From duke at openjdk.org  Fri Sep  5 10:15:32 2025
From: duke at openjdk.org (mazhen)
Date: Fri, 5 Sep 2025 10:15:32 GMT
Subject: Withdrawn: 8303612:
 runtime/StackGuardPages/TestStackGuardPagesNative.java fails with exit code
 139
In-Reply-To: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
References: <oRl4abf8ZV5qD9GNScJMRwwZD2PkdiDGJykDFs1Cmgo=.8c961e33-291f-4ba1-b494-ad5eab7ee72c@github.com>
Message-ID: <mT07iUq3fGx0OO6Mun7k1LqNE4cJcdlEzudlWJ3vol0=.afffc0be-4925-4216-b762-bb3dadd0153d@github.com>

On Mon, 9 Jun 2025 06:53:20 GMT, mazhen <duke at openjdk.org> wrote:

> This pull request addresses an issue in `runtime/StackGuardPages/TestStackGuardPagesNative` where the native test component (`exeinvoke.c`) exhibited platform-dependent behavior and did not fully align with the intended test objectives for verifying stack guard page removal on thread detachment.
> 
> **Summary of the Problem:**
> 
> The `test_native_overflow_initial` scenario within `TestStackGuardPagesNative` showed inconsistent results:
> *   On certain Linux distributions (e.g., CentOS 7), the test would hang and eventually time out during its second phase of stack allocation.
> *   On other distributions (e.g., Ubuntu 24), the test would pass, but this pass was found to be coincidental, relying on an unintended `SEGV_MAPERR` to terminate a loop that should have had a defined exit condition.
> 
> The core issue was that the native code's second stack overflow attempt, designed to check for guard page removal, used an unbounded loop. Its termination (and thus the test's outcome) depended on platform-specific OS behavior regarding extensive stack allocation after guard pages are supposedly modified.
> 
> **Test Objective Analysis:**
> 
> The primary goal of `TestStackGuardPagesNative`, particularly for the initial thread (`test_native_overflow_initial`), is to:
> 1.  **Verify Guard Page Presence:** Confirm that when a native thread is attached to the JVM, a deliberate stack overflow triggers a `SIGSEGV` with `si_code = SEGV_ACCERR`, indicating an active stack guard page.
> 2.  **Verify Guard Page Removal/Modification:** After the thread detaches from the JVM via `DetachCurrentThread()`, confirm that the previously active stack guard page is no longer enforcing the same strict protection. This is ideally demonstrated by successfully allocating stack space up to the depth that previously caused the `SEGV_ACCERR`, **without encountering any signal**.
> 
> **How the Original Implementation Deviated from the Test Intent:**
> 
> The native `do_overflow` function, when invoked for the second phase (to check guard page removal), implemented an unconditional `for(;;)` loop.
> *   **Intended Logic vs. Actual Behavior:** The test intended for this second phase to demonstrate that allocations up to the prior failure depth are now "clean" (no `SEGV_ACCERR`). However, the unbounded loop meant:
>     *   On systems like CentOS 7, where deep stack allocation without an immediate `SEGV_MAPERR` was possible, this loop ran for an excessive duration, leading to a hang.
>     *   On systems like Ubuntu 24, the loop *...

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/25689

From duke at openjdk.org  Fri Sep  5 10:18:26 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 5 Sep 2025 10:18:26 GMT
Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit
Message-ID: <Mjgyf1JzzcIW1g5vMi94LaW0rqar7zCBCIO5xBpwJuo=.7e0dc3a2-b6c2-414c-acfb-429b2c9badde@github.com>

Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification.

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

Commit messages:
 - Add comment

Changes: https://git.openjdk.org/jdk/pull/27115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366970
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27115/head:pull/27115

PR: https://git.openjdk.org/jdk/pull/27115

From coleenp at openjdk.org  Fri Sep  5 11:40:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 11:40:41 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654
Message-ID: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>

java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
Tested with tier1.

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

Commit messages:
 - 8366908: Use a different class for testing JDK-8351654

Changes: https://git.openjdk.org/jdk/pull/27116/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366908
  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27116/head:pull/27116

PR: https://git.openjdk.org/jdk/pull/27116

From stefank at openjdk.org  Fri Sep  5 11:54:10 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Sep 2025 11:54:10 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v7]
In-Reply-To: <RtuH3bMLW-fRnzXj9oXB3aSmkmoB0EisYN0fz_l11h0=.73d30ea8-b798-410b-be3d-21b2aa5c70e4@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <RtuH3bMLW-fRnzXj9oXB3aSmkmoB0EisYN0fz_l11h0=.73d30ea8-b798-410b-be3d-21b2aa5c70e4@github.com>
Message-ID: <gjguqq5YfPLvyNjMJgZopr4KnGYTauUunWOFTv2xU1c=.46f3d56e-ba1b-4824-8722-d2d513a60616@github.com>

On Fri, 5 Sep 2025 09:02:27 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
>> The values are checked against INT_MAX and clamped.
>> 
>> Tests: tiers 1-5.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied.

Thanks for fixing!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26859#pullrequestreview-3189068068

From liach at openjdk.org  Fri Sep  5 12:56:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 12:56:10 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654
In-Reply-To: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
Message-ID: <oGdB71kz1pjIinBIZJ47SaFCqbiIzu2d4uiqH_95ZQs=.e0a4ad7c-f29c-4f0d-99e4-6c6f0d8d68be@github.com>

On Fri, 5 Sep 2025 11:35:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
> Tested with tier1.

test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 167:

> 165:                 inst.addTransformer(new BadTransformer());
> 166:                 Class<?> cls = Class.forName(CLASS_TO_BREAK);
> 167:                 System.out.println("class loaded" + cls);

Isn't this println redundant, because the VerifyError is supposed to be thrown before? I think the old code uses `Durations.ofHours` to trigger verification and initialization of Duration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2325017388

From phubner at openjdk.org  Fri Sep  5 14:03:55 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 5 Sep 2025 14:03:55 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v3]
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <vYQOpSv_WGF7Hn-70eaqaFpJ_nyidYD0XvGdNGlj6T0=.ad875cd1-2f1b-4554-a7b5-2248d5195a31@github.com>

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Clean up method a bit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26894/files
  - new: https://git.openjdk.org/jdk/pull/26894/files/c6da1f57..3a87b884

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26894&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26894&range=01-02

  Stats: 28 lines in 1 file changed: 8 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26894/head:pull/26894

PR: https://git.openjdk.org/jdk/pull/26894

From phubner at openjdk.org  Fri Sep  5 14:03:56 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 5 Sep 2025 14:03:56 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v2]
In-Reply-To: <v7yPM9GzgnsxyXkmearyXHPLF0vSJeF4MZgkZpDXy9k=.e1d0c818-6a8b-4d83-b428-9a5451a433c4@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <3Uw3Klwp5p9lzY5QWHEBSShtGyAF5S74ZugszJV-6tw=.34cf5365-9c9b-437e-bc04-e326738b6112@github.com>
 <v7yPM9GzgnsxyXkmearyXHPLF0vSJeF4MZgkZpDXy9k=.e1d0c818-6a8b-4d83-b428-9a5451a433c4@github.com>
Message-ID: <ItjXowJ9brlHbIbwCF4CT-FDh9EhVy7_x4LhZNSdr0k=.d9a31108-6566-4d74-8a43-76df59463d68@github.com>

On Thu, 4 Sep 2025 17:49:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Incorporate reviewer feedback.
>>  - Merge branch 'master' into JDK-8364103
>>  - Refactor stack trace printing to use stringStream.
>
> Looks okay as is, but there is some optional tidying up that could be done.

Thanks for the suggestions, @kimbarrett. I've cleaned up as you suggested, which also gave way to fuse some of the conditionals, making it more readable overall. Could you take a look to double check no semantics were changed during the transformation?

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

PR Comment: https://git.openjdk.org/jdk/pull/26894#issuecomment-3258456533

From tschatzl at openjdk.org  Fri Sep  5 14:12:11 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 5 Sep 2025 14:12:11 GMT
Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit
In-Reply-To: <Mjgyf1JzzcIW1g5vMi94LaW0rqar7zCBCIO5xBpwJuo=.7e0dc3a2-b6c2-414c-acfb-429b2c9badde@github.com>
References: <Mjgyf1JzzcIW1g5vMi94LaW0rqar7zCBCIO5xBpwJuo=.7e0dc3a2-b6c2-414c-acfb-429b2c9badde@github.com>
Message-ID: <cWDhzzJPxAyV38TW_2pyBwdePwHiLW2w4rpqHalGQq8=.2fa81cf7-3f10-4983-9ada-b9fbd0177d65@github.com>

On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification.

Looks good, but maybe it makes sense to add an assert-flag to the `Thread` that indicates whether the `Thread` has been terminated, and fail here.

(My change request is purely about the additional newline, the suggestion above is just something that is possible. Not sure it is worth).

src/hotspot/share/services/cpuTimeUsage.hpp line 33:

> 31: // It may be unsafe to call these methods during VM exit
> 32: // as threads are terminating
> 33: 

Suggestion:



Proper sentences need a full stop at the end too.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27115#pullrequestreview-3189526429
PR Review Comment: https://git.openjdk.org/jdk/pull/27115#discussion_r2325203856

From coleenp at openjdk.org  Fri Sep  5 15:33:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 15:33:11 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654
In-Reply-To: <oGdB71kz1pjIinBIZJ47SaFCqbiIzu2d4uiqH_95ZQs=.e0a4ad7c-f29c-4f0d-99e4-6c6f0d8d68be@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <oGdB71kz1pjIinBIZJ47SaFCqbiIzu2d4uiqH_95ZQs=.e0a4ad7c-f29c-4f0d-99e4-6c6f0d8d68be@github.com>
Message-ID: <ZLWmGYWYITgEBWp-l-J0zZbCY1vReZzrciaoNYNoHBc=.7859ce4e-3761-4f07-b020-f0aed2e1e1cd@github.com>

On Fri, 5 Sep 2025 12:53:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 167:
> 
>> 165:                 inst.addTransformer(new BadTransformer());
>> 166:                 Class<?> cls = Class.forName(CLASS_TO_BREAK);
>> 167:                 System.out.println("class loaded" + cls);
> 
> Isn't this println redundant, because the VerifyError is supposed to be thrown before? I think the old code uses `Durations.ofHours` to trigger verification and initialization of Duration.

It is not reached since we throw the VerifyError at line 166.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2325411714

From coleenp at openjdk.org  Fri Sep  5 15:43:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 15:43:26 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
Message-ID: <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>

> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
> Tested with tier1.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  remove unreachable line.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27116/files
  - new: https://git.openjdk.org/jdk/pull/27116/files/b3480350..0616cf65

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27116/head:pull/27116

PR: https://git.openjdk.org/jdk/pull/27116

From liach at openjdk.org  Fri Sep  5 15:43:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 15:43:27 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
Message-ID: <r6Vqn6I5UC95L4q-uVfzuNI9lynOMD6781p16sxYLbs=.b478cc05-2b3b-4293-ad0a-ccdcbc924cc2@github.com>

On Fri, 5 Sep 2025 15:40:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreachable line.

Thanks, looks good from a ClassFile API perspective.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27116#pullrequestreview-3189862085

From liach at openjdk.org  Fri Sep  5 16:03:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 16:03:11 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
References: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
 <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
Message-ID: <lZpGkz9YtUlLgIaeDGcNwofgiW9HesvlGImZhSjfiUg=.e367f0c7-1365-4f00-8f77-f2881262888c@github.com>

On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright

Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered?

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

PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3258880424

From lmesnik at openjdk.org  Fri Sep  5 17:09:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Sep 2025 17:09:16 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
Message-ID: <HHxCDOPu83yVPRJW7z1zwmDrP8HXmo16i8RrnBjae-0=.7a1016c5-ff5b-4bc9-9dab-96b8d87e861a@github.com>

On Fri, 5 Sep 2025 15:43:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreachable line.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27116#pullrequestreview-3190193463

From coleenp at openjdk.org  Fri Sep  5 18:42:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 18:42:12 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
Message-ID: <Vc6mCH_boSnJwOyxTsWzbekNh2IOvxDbAqXt5ZaUMc8=.b42ac1dd-228c-4395-855b-a10146c6f0c8@github.com>

On Fri, 5 Sep 2025 15:43:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreachable line.

Thanks Chen and Leonid.

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

PR Comment: https://git.openjdk.org/jdk/pull/27116#issuecomment-3259388793

From azafari at openjdk.org  Fri Sep  5 18:45:17 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 5 Sep 2025 18:45:17 GMT
Subject: RFR: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int' [v3]
In-Reply-To: <yU_WJ0o3hjfdLIexyV0k2XkT7sH40IJRtXkMGkrDuY4=.b6bad22d-0c91-4e6a-acd0-ba1c371e6b38@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
 <x2XW0ywYSy-9Tqh-Mzrhd3X1o8MTo5rADg48p92rpDo=.a3e4e6cf-ce98-48c7-b90d-cfa22b130e54@github.com>
 <yU_WJ0o3hjfdLIexyV0k2XkT7sH40IJRtXkMGkrDuY4=.b6bad22d-0c91-4e6a-acd0-ba1c371e6b38@github.com>
Message-ID: <d3JnHrCzptCBy-llvGycgRkDMK4JfCEB0fnLj5ETbd0=.c5059f74-1184-4f64-b8b8-248c69576500@github.com>

On Thu, 28 Aug 2025 01:12:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved invalid detection and error messages
>
> Any removal of the flags would be in the future. We would have to deprecate first and follow a three step process - though these are not hotspot flags per-se (-XX) but non-standard launcher flags (-X).

Thanks for reviews, @dholmes-ora and @stefank.

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

PR Comment: https://git.openjdk.org/jdk/pull/26859#issuecomment-3259395540

From azafari at openjdk.org  Fri Sep  5 18:45:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 5 Sep 2025 18:45:18 GMT
Subject: Integrated: 8353468: [ubsan] arguments.cpp:2422:23: runtime error:
 2.14748e+11 is outside the range of representable values of type 'int'
In-Reply-To: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
References: <plQ5n7EjsekIjeY431_mBeo4rfcH39SVdPWogF2rT44=.20180c89-665e-4054-8625-1b04f8306b3b@github.com>
Message-ID: <NsDC8Cp337j4GvZ3dawLAnwJYkuTGpY1dJl9_JVMZKg=.3d8d1125-b582-4f5f-95cf-f3d06a93c920@github.com>

On Wed, 20 Aug 2025 12:12:01 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In converting values of `-XMinf` and `-XMaxf` options to `int`, overflow was not checked. 
> The values are checked against INT_MAX and clamped.
> 
> Tests: tiers 1-5.

This pull request has now been integrated.

Changeset: c6c451ac
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6c451ac392cdb545ab43dd46918eca6c47cc5f0
Stats:     89 lines in 2 files changed: 60 ins; 6 del; 23 mod

8353468: [ubsan] arguments.cpp:2422:23: runtime error: 2.14748e+11 is outside the range of representable values of type 'int'

Reviewed-by: stefank, dholmes

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

PR: https://git.openjdk.org/jdk/pull/26859

From dlong at openjdk.org  Fri Sep  5 19:47:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 5 Sep 2025 19:47:08 GMT
Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed
 [v2]
In-Reply-To: <lZpGkz9YtUlLgIaeDGcNwofgiW9HesvlGImZhSjfiUg=.e367f0c7-1365-4f00-8f77-f2881262888c@github.com>
References: <GGNRha5VoOoo6_K-eqSVMm3BZcAvdWwZnlppDxonETw=.f080bc29-ef1e-4002-a5dd-c3bf2931c8a7@github.com>
 <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com>
 <lZpGkz9YtUlLgIaeDGcNwofgiW9HesvlGImZhSjfiUg=.e367f0c7-1365-4f00-8f77-f2881262888c@github.com>
Message-ID: <IhTskRBGoYuTd1pOAMSmDkOruM5R0DtHrxwpJ_Lk_Yg=.fdc5bc0d-55b2-420a-bc5c-8e7a046943bc@github.com>

On Fri, 5 Sep 2025 16:00:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered?

I think Oracle has enough test coverage in closed tests, but it wouldn't hurt to have more open tests.  All I could find in a quick search was open/test/hotspot/jtreg/runtime/handlerInTry.

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

PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3259558199

From duke at openjdk.org  Sat Sep  6 16:12:14 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 6 Sep 2025 16:12:14 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
Message-ID: <xKt0kGSUpzTB5-XIvzMHeJHZqvu0_31997fu1X8Y5yQ=.f6235e63-8aed-46d5-9822-17c20f0d82f3@github.com>

On Fri, 5 Sep 2025 15:43:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreachable line.

test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 93:

> 91:                     builder.with(element);
> 92:                 });
> 93:                 var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().stringValue().equals("parse"), methodTransform);

This?can?use [`Utf8Entry::equalsString`] to?avoid unnecessarily inflating all?method?names:
Suggestion:

                var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().equalsString("parse"), methodTransform);


[`Utf8Entry::equalsString`]: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/classfile/constantpool/Utf8Entry.html#equalsString%28java.lang.String%29

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2327805601

From liach at openjdk.org  Sat Sep  6 17:10:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 Sep 2025 17:10:10 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <xKt0kGSUpzTB5-XIvzMHeJHZqvu0_31997fu1X8Y5yQ=.f6235e63-8aed-46d5-9822-17c20f0d82f3@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
 <xKt0kGSUpzTB5-XIvzMHeJHZqvu0_31997fu1X8Y5yQ=.f6235e63-8aed-46d5-9822-17c20f0d82f3@github.com>
Message-ID: <G_JdjxYDggzZcC4UtkAslmtd6NiwCAK6IzPwmeG79J0=.1d550f8f-4539-4d89-ab6b-773607163612@github.com>

On Sat, 6 Sep 2025 16:07:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unreachable line.
>
> test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 93:
> 
>> 91:                     builder.with(element);
>> 92:                 });
>> 93:                 var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().stringValue().equals("parse"), methodTransform);
> 
> This?can?use [`Utf8Entry::equalsString`] to?avoid unnecessarily inflating all?method?names:
> Suggestion:
> 
>                 var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().equalsString("parse"), methodTransform);
> 
> 
> [`Utf8Entry::equalsString`]: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/classfile/constantpool/Utf8Entry.html#equalsString%28java.lang.String%29

True, but I don't think we need to be this careful for tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2327950682

From coleenp at openjdk.org  Sun Sep  7 18:12:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sun, 7 Sep 2025 18:12:11 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <G_JdjxYDggzZcC4UtkAslmtd6NiwCAK6IzPwmeG79J0=.1d550f8f-4539-4d89-ab6b-773607163612@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
 <xKt0kGSUpzTB5-XIvzMHeJHZqvu0_31997fu1X8Y5yQ=.f6235e63-8aed-46d5-9822-17c20f0d82f3@github.com>
 <G_JdjxYDggzZcC4UtkAslmtd6NiwCAK6IzPwmeG79J0=.1d550f8f-4539-4d89-ab6b-773607163612@github.com>
Message-ID: <0xiMMkjr_HK8ieqErSQoj3ehKtL95tkndBA_JJUUsp0=.381d304f-ffae-4032-8630-3772dd6380dd@github.com>

On Sat, 6 Sep 2025 17:07:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java line 93:
>> 
>>> 91:                     builder.with(element);
>>> 92:                 });
>>> 93:                 var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().stringValue().equals("parse"), methodTransform);
>> 
>> This?can?use [`Utf8Entry::equalsString`] to?avoid unnecessarily inflating all?method?names:
>> Suggestion:
>> 
>>                 var classTransform = ClassTransform.transformingMethods(mm -> mm.methodName().equalsString("parse"), methodTransform);
>> 
>> 
>> [`Utf8Entry::equalsString`]: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/classfile/constantpool/Utf8Entry.html#equalsString%28java.lang.String%29
>
> True, but I don't think we need to be this careful for tests.

True, but why not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2328788477

From jwaters at openjdk.org  Sun Sep  7 18:35:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 7 Sep 2025 18:35:13 GMT
Subject: RFR: 8343249: [Windows] Implement SpinPause [v4]
In-Reply-To: <MFq534jcGDu_tQflEI2gznmctlBZGgW-W2iPXD31-Eo=.e065b2ec-d105-439b-be58-ead68ba4ff31@github.com>
References: <C0Be57gD7kCuqSZ93wg-roMV3ya9F4z1S_oh5ZY43p4=.b8250e0a-6af1-4a37-a8df-d0c67d2d5508@github.com>
 <MFq534jcGDu_tQflEI2gznmctlBZGgW-W2iPXD31-Eo=.e065b2ec-d105-439b-be58-ead68ba4ff31@github.com>
Message-ID: <d8iQ_3woCU356i6NUSTXJjUTOttjHN3binsIKtGusRo=.3d2f5bf4-26da-41e0-bf0f-986997b9f26a@github.com>

On Mon, 18 Nov 2024 06:08:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> SpinPause is currently not implemented on any Windows platforms, due to a lack of access to assembly in the Microsoft compiler. The YieldProcessor macro can act as a stand in for this purpose, as it compiles down to a single pause instruction on x64 (Which seems to be all that one needs to implement SpinPause in HotSpot). I am less certain about the Windows/ARM64 implementation. There, YieldProcessor compiles down to dmb ishst; yield and I am unsure whether that is a correct SpinPause implementation. If need be, I can retract the ARM64 implementation and only have this for x86
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'openjdk:master' into patch-13
>  - Merge branch 'master' into patch-13
>  - Swap to handwritten assembly to implement SpinPause in os_windows_aarch64.cpp
>  - YieldProcessor in os_windows_aarch64.cpp
>  - 8343249

Sorry for leaving this to wait for so long. I'm not sure what to benchmark this with though, not sure if JMH is suitable for this, and I'm not very familiar with JMH anyway

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

PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-3263960294

From liach at openjdk.org  Sun Sep  7 18:57:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 Sep 2025 18:57:13 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v2]
In-Reply-To: <0xiMMkjr_HK8ieqErSQoj3ehKtL95tkndBA_JJUUsp0=.381d304f-ffae-4032-8630-3772dd6380dd@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <xMd864ctXOvbhF-nkIWcvJmIKjZt2dgOwFZxyfECLbo=.985c4fbf-4e7e-485c-acb7-741abee55027@github.com>
 <xKt0kGSUpzTB5-XIvzMHeJHZqvu0_31997fu1X8Y5yQ=.f6235e63-8aed-46d5-9822-17c20f0d82f3@github.com>
 <G_JdjxYDggzZcC4UtkAslmtd6NiwCAK6IzPwmeG79J0=.1d550f8f-4539-4d89-ab6b-773607163612@github.com>
 <0xiMMkjr_HK8ieqErSQoj3ehKtL95tkndBA_JJUUsp0=.381d304f-ffae-4032-8630-3772dd6380dd@github.com>
Message-ID: <Uv9CnwzdbKcA1PB6Y9tPk6AwaOcO-h2_KSr-vu-Zjv0=.fcc37499-0f11-4a82-83fe-6716fa5000e5@github.com>

On Sun, 7 Sep 2025 18:09:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> True, but I don't think we need to be this careful for tests.
>
> True, but why not?

I can re-approve if you push such a change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27116#discussion_r2328803879

From dholmes at openjdk.org  Mon Sep  8 05:02:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 05:02:16 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v3]
In-Reply-To: <vYQOpSv_WGF7Hn-70eaqaFpJ_nyidYD0XvGdNGlj6T0=.ad875cd1-2f1b-4554-a7b5-2248d5195a31@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <vYQOpSv_WGF7Hn-70eaqaFpJ_nyidYD0XvGdNGlj6T0=.ad875cd1-2f1b-4554-a7b5-2248d5195a31@github.com>
Message-ID: <P4_kcu6AnfVOfAXK3c-cKf9m5_6FNtX5s9HwDc29xvM=.06912191-c451-4e0f-99b4-2a2a24fb5545@github.com>

On Fri, 5 Sep 2025 14:03:55 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up method a bit.

Changes look good. One suggestion around the lengthy new comment.

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 2590:

> 2588: // Presumably to avoid interleaving with other threads.
> 2589: // The current version retains that spirit by writing to a stringStream first before
> 2590: // flushing everything into the outputStream at once.

Suggestion:

// The output is formatted into a stringStream and written to the outputStream in one step.

No need to comment on history as such.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3194927167
PR Review Comment: https://git.openjdk.org/jdk/pull/26894#discussion_r2329107480

From dholmes at openjdk.org  Mon Sep  8 06:05:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 06:05:13 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <N420UA8Z4w4r83jl-5CBmUlEiTVL_c-WLMD5ytQ4Cck=.a43d2b97-cea0-4705-a054-aabf6acf1dd4@github.com>

On Thu, 28 Aug 2025 10:15:47 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

Approach of using integer arithmetic seems reasonable to me. Some suggestions on the way it is commented.

Thanks

src/hotspot/share/cds/archiveBuilder.cpp line 374:

> 372: 
> 373:     // At run time, we will mmap the dynamic archive at my_archive_requested_bottom
> 374:     // Zero is acceptable for _requested_static_archive_bottom. Using casts to avoid UBSAN complain of nullptr arithmetic.

Suggestion:

    // As zero is allowed for _requested_static_archive_bottom, use integer arithmetic to avoid UB pointer arithmetic.

And similarly for other comments.

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

PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3195058563
PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2329210001

From dholmes at openjdk.org  Mon Sep  8 06:47:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 06:47:11 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
In-Reply-To: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
Message-ID: <nmovWDUO5HeH6YtGqaYmRKTebEtPDOf86gprYef7eEc=.80243da6-2cf4-4134-b884-d5c47a17e654@github.com>

On Fri, 5 Sep 2025 09:51:58 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.
> 
> #### Problem
> 
> The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.
> 
> *   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
> *   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.
> 
> #### Solution
> 
> The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.
> 
> This change makes the test's logic robust and its behavior consistent across different environments.

Actual fix looks good, but the test has to remain in the PL.

Thanks

test/hotspot/jtreg/ProblemList.txt line 109:

> 107: runtime/os/TestTracePageSizes.java#Parallel 8267460 linux-aarch64
> 108: runtime/os/TestTracePageSizes.java#Serial 8267460 linux-aarch64
> 109: runtime/StackGuardPages/TestStackGuardPagesNative.java 8303612 linux-all

You can't remove this from the ProblemList unless 8303612 is actually fixed.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27114#pullrequestreview-3195163355
PR Review Comment: https://git.openjdk.org/jdk/pull/27114#discussion_r2329286591

From duke at openjdk.org  Mon Sep  8 07:13:19 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 8 Sep 2025 07:13:19 GMT
Subject: Integrated: 8366864: Sort os/linux includes
In-Reply-To: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
References: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
Message-ID: <FQ1O9m_C3LBFG_aCMCBEk9jfje6PhjCZWxIl_73E0Tg=.fb790423-4def-47b1-9330-e3cfd3ff15ad@github.com>

On Thu, 4 Sep 2025 09:28:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/cpu/linux using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

This pull request has now been integrated.

Changeset: 051f39e1
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/051f39e12ce8845d13c7d4813dabc556a834892d
Stats:     115 lines in 14 files changed: 52 ins; 50 del; 13 mod

8366864: Sort os/linux includes

Reviewed-by: ayang, dholmes

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

PR: https://git.openjdk.org/jdk/pull/27088

From dholmes at openjdk.org  Mon Sep  8 07:13:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 07:13:18 GMT
Subject: RFR: 8366864: Sort os/linux includes
In-Reply-To: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
References: <2zVJhDpuPBlSgXHEcsdOX4ijNcGEhHsMx4wByIeVN9g=.48c75171-86a7-4770-bf9b-3d95dce04f44@github.com>
Message-ID: <BjvKmwULRlMFvqc4xFfr_S3XGAWXfoBpVHvIZ_MMQxg=.f7835ed8-40f1-4888-b636-3ee057e218f6@github.com>

On Thu, 4 Sep 2025 09:28:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/cpu/linux using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted.java`.

Seems okay.

Don't forget you need two reviews.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27088#pullrequestreview-3195230696

From dholmes at openjdk.org  Mon Sep  8 07:15:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 07:15:12 GMT
Subject: RFR: 8366970: CPUTimeUsage: Add comment about usage during VM exit
In-Reply-To: <Mjgyf1JzzcIW1g5vMi94LaW0rqar7zCBCIO5xBpwJuo=.7e0dc3a2-b6c2-414c-acfb-429b2c9badde@github.com>
References: <Mjgyf1JzzcIW1g5vMi94LaW0rqar7zCBCIO5xBpwJuo=.7e0dc3a2-b6c2-414c-acfb-429b2c9badde@github.com>
Message-ID: <PKb4hLYf3XC39d7-xpAP-y659LIL-jCGTMSw0d2ykug=.50522d5d-ff62-401a-b294-1f0f420622be@github.com>

On Fri, 5 Sep 2025 10:06:32 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Some of the methods in CPUTimeUsage make a query on the underlying threads. Calling those methods during VM exit is therefore unsafe. This PR adds a comment to provide clarification.

If the methods could be unsafe surely they should be checking for that, or else ensuring they are not used in unsafe contexts.

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

PR Review: https://git.openjdk.org/jdk/pull/27115#pullrequestreview-3195241431

From azafari at openjdk.org  Mon Sep  8 08:26:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 8 Sep 2025 08:26:28 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v2]
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <dGDXSIUokH9sBJIxDhUCirzx01Fe1SVZDWGNqsR7b5o=.084c7b47-2a12-41ef-b672-f3b6061faafa@github.com>

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  comments improved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26983/files
  - new: https://git.openjdk.org/jdk/pull/26983/files/531a47d1..6beeecb3

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

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983

PR: https://git.openjdk.org/jdk/pull/26983

From azafari at openjdk.org  Mon Sep  8 08:44:47 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 8 Sep 2025 08:44:47 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v3]
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <_jo96ToBom5YqsnzX9NI1eG3oU8jUU9tYwcFIVpgiSA=.345f8d63-0aff-481a-8517-af8293e0e4ea@github.com>

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset
 - comments improved
 - 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

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

Changes: https://git.openjdk.org/jdk/pull/26983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=02
  Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983

PR: https://git.openjdk.org/jdk/pull/26983

From azafari at openjdk.org  Mon Sep  8 09:03:17 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 8 Sep 2025 09:03:17 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <ax57kZCNn9wDFzZkQK1tQASEVnJHSTRhmTPin2zLz4A=.3df587bb-8bd8-47aa-a3a9-37d7323d5c30@github.com>

On Mon, 8 Sep 2025 08:55:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`.
> 
> Tests:
> tiers1-5, main platforms, debug/product

Waiting for [8366363](https://bugs.openjdk.org/browse/JDK-8366363) to be integrated. Those changes to be merged here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27137#issuecomment-3265298064

From azafari at openjdk.org  Mon Sep  8 09:03:16 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 8 Sep 2025 09:03:16 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure
Message-ID: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>

The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`.

Tests:
tiers1-5, main platforms, debug/product

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

Commit messages:
 - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure

Changes: https://git.openjdk.org/jdk/pull/27137/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366241
  Stats: 195 lines in 12 files changed: 38 ins; 93 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/27137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27137/head:pull/27137

PR: https://git.openjdk.org/jdk/pull/27137

From phubner at openjdk.org  Mon Sep  8 09:47:56 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 8 Sep 2025 09:47:56 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v4]
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/classfile/javaClasses.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26894/files
  - new: https://git.openjdk.org/jdk/pull/26894/files/3a87b884..21049190

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26894&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26894&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26894/head:pull/26894

PR: https://git.openjdk.org/jdk/pull/26894

From duke at openjdk.org  Mon Sep  8 11:00:22 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 8 Sep 2025 11:00:22 GMT
Subject: RFR: 8367085: Sort os/posix includes
Message-ID: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>

In this PR I sort includes in `os/posix` using `SortIncludes.java`.

Passes `tier1`.

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

Commit messages:
 - comments
 - sort

Changes: https://git.openjdk.org/jdk/pull/27141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367085
  Stats: 32 lines in 8 files changed: 15 ins; 14 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27141/head:pull/27141

PR: https://git.openjdk.org/jdk/pull/27141

From coleenp at openjdk.org  Mon Sep  8 11:31:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Sep 2025 11:31:46 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v3]
In-Reply-To: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
Message-ID: <e9hM1m0O0fq7yMg_HBSk7yTVp1uQePIibuYDguBW-ck=.39c06159-b585-4a6f-a9e6-55b744f0eef5@github.com>

> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
> Tested with tier1.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27116/files
  - new: https://git.openjdk.org/jdk/pull/27116/files/0616cf65..e95eff7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27116&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27116&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27116/head:pull/27116

PR: https://git.openjdk.org/jdk/pull/27116

From azafari at openjdk.org  Mon Sep  8 12:15:13 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 8 Sep 2025 12:15:13 GMT
Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14]
In-Reply-To: <e5tpytmOK0po-x06p0EoeruRxvTlnVeozbNp0-15550=.ec1abfed-d222-4a74-8669-bb38e2300663@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
 <e5tpytmOK0po-x06p0EoeruRxvTlnVeozbNp0-15550=.ec1abfed-d222-4a74-8669-bb38e2300663@github.com>
Message-ID: <Z7NlZlfM8p1BT1sR7dXm391jD2k2MDH2JVuxNrbv7W4=.93f287c4-c4ef-449e-b440-8be7064b1d43@github.com>

On Thu, 4 Sep 2025 11:46:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed const-ness

Still good. Thanks!

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3196243257

From ayang at openjdk.org  Mon Sep  8 13:08:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Sep 2025 13:08:10 GMT
Subject: RFR: 8367085: Sort os/posix includes
In-Reply-To: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
References: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
Message-ID: <AMzcOED4xVCAp0mmCa_veoTdMw9_nGQG_h5wM9U5_Gk=.8ddbd9ea-5719-457f-9437-0df99d76629d@github.com>

On Mon, 8 Sep 2025 10:54:54 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I sort includes in `os/posix` using `SortIncludes.java`.
> 
> Passes `tier1`.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27141#pullrequestreview-3196456850

From liach at openjdk.org  Mon Sep  8 13:21:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Sep 2025 13:21:12 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v3]
In-Reply-To: <e9hM1m0O0fq7yMg_HBSk7yTVp1uQePIibuYDguBW-ck=.39c06159-b585-4a6f-a9e6-55b744f0eef5@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <e9hM1m0O0fq7yMg_HBSk7yTVp1uQePIibuYDguBW-ck=.39c06159-b585-4a6f-a9e6-55b744f0eef5@github.com>
Message-ID: <fa4waJBGDKtCxn6Eaq57WawI1FwnnceCeHRVszf4D7A=.a6a4b731-9117-4752-af0e-19bdd7d3369b@github.com>

On Mon, 8 Sep 2025 11:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27116#pullrequestreview-3196504393

From coleenp at openjdk.org  Mon Sep  8 15:52:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Sep 2025 15:52:33 GMT
Subject: RFR: 8366908: Use a different class for testing JDK-8351654 [v3]
In-Reply-To: <e9hM1m0O0fq7yMg_HBSk7yTVp1uQePIibuYDguBW-ck=.39c06159-b585-4a6f-a9e6-55b744f0eef5@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
 <e9hM1m0O0fq7yMg_HBSk7yTVp1uQePIibuYDguBW-ck=.39c06159-b585-4a6f-a9e6-55b744f0eef5@github.com>
Message-ID: <tSHsnnOwFB7tSTtSt4SY3xjjCGY9-HRiRoRYvaIvoSE=.5986aa53-6d54-42ad-9588-1777bbd4c878@github.com>

On Mon, 8 Sep 2025 11:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
>> Tested with tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/verifier/CFLH/TestVerify.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Thanks Chen for re-approving.

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

PR Comment: https://git.openjdk.org/jdk/pull/27116#issuecomment-3266925717

From coleenp at openjdk.org  Mon Sep  8 15:52:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Sep 2025 15:52:34 GMT
Subject: Integrated: 8366908: Use a different class for testing JDK-8351654
In-Reply-To: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
References: <qf6g1AX9HcrtaclxfY2K17k1mDskctDky5Lo5ZlE570=.852ae2e6-1870-4e45-ace5-e53d97e32617@github.com>
Message-ID: <DZvD-o1Ui5vsM-5eqUV5qeo-Ljr5LOT8M5xfLMyYtl4=.13af1511-2e95-4114-86d9-a5de73fc7d43@github.com>

On Fri, 5 Sep 2025 11:35:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> java.time.Duration is a migrated class (to be a value type) in the Valhalla repo, so it's preloaded, which causes this test to fail.  Using a different java.base class achieves the purpose of this test.
> Tested with tier1.

This pull request has now been integrated.

Changeset: 6765a9d7
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6765a9d775b5bd3d1b36090038060762f976d174
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8366908: Use a different class for testing JDK-8351654

Reviewed-by: liach, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/27116

From duke at openjdk.org  Mon Sep  8 19:26:58 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Mon, 8 Sep 2025 19:26:58 GMT
Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on
 Windows aarch64 [v3]
In-Reply-To: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
Message-ID: <dY13kLWXKmfblE6nwOi7LIi7Yri_FO6vUIRqaXFM-ck=.11fd8595-9790-4c1e-a20b-3760ded11e41@github.com>

> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change.
> 
> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler.
> 
> Exceptions with the DBG_PRINTEXCEPTION_C  exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code)

Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:

  Move safefetch handling into existing _M_ARM64 block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27074/files
  - new: https://git.openjdk.org/jdk/pull/27074/files/b35b47fb..9829641a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27074&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27074/head:pull/27074

PR: https://git.openjdk.org/jdk/pull/27074

From kbarrett at openjdk.org  Mon Sep  8 21:11:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 8 Sep 2025 21:11:17 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v4]
In-Reply-To: <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
Message-ID: <Uaqd_ZzEgxgsByumfgLjf2CeHBdKfu-vhmG52lYGKlo=.c87a4801-fdc1-496b-bb1c-8df29030ac7e@github.com>

On Mon, 8 Sep 2025 09:47:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/javaClasses.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Looks even better.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3198195337

From dholmes at openjdk.org  Tue Sep  9 06:42:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 06:42:11 GMT
Subject: RFR: 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on
 Windows aarch64 [v3]
In-Reply-To: <dY13kLWXKmfblE6nwOi7LIi7Yri_FO6vUIRqaXFM-ck=.11fd8595-9790-4c1e-a20b-3760ded11e41@github.com>
References: <-IvxYqq4iPQBZGLl6KrbvHmWIoH0sU4KjLDUHIQBxtc=.303d1f14-fc29-418d-ae32-e05d239e1c0b@github.com>
 <dY13kLWXKmfblE6nwOi7LIi7Yri_FO6vUIRqaXFM-ck=.11fd8595-9790-4c1e-a20b-3760ded11e41@github.com>
Message-ID: <3Ei-9_RM4I2HcOW-BYcgMTWUByjma1Mq3vP1X9amd6g=.70de8ae0-5383-4a00-8857-9f726d486886@github.com>

On Mon, 8 Sep 2025 19:26:58 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The Windows AArch64 OpenJDK build uses vectored exception handling. The implementation registers a custom vectored exception handler, which calls the exception filter function that is shared with the x64 platform. However, this call only happens when using -xcomp. This has the side effect of not running the JVM error handling code that would create a core dump if only the interpreter is used. This change fixes this issue by unconditionally using the same exception handler as Windows x64. The CreateCoredumpOnCrash test now passes with this change.
>> 
>> Although vectored exception handling is used on Windows AArch64, the implementation currently uses the same safefetch implementation as x64, which relies on structured exception handling. This change fixes safefetch on Windows AArch64 to not use the SEH implemenation (in safefetch_windows.hpp). This change defines the static assembly language for the fetching code like the other aarch64 platforms have done and updates the exception handler to recognize exceptions from the safe fetch assembly instructions. This came up because the NMT gtests started failing after the change to the exception handler.
>> 
>> Exceptions with the DBG_PRINTEXCEPTION_C  exception code are also encountered in routine execution on Windows AArch64 so I excluded them from causing error reporting, similar to how EXCEPTION_BREAKPOINT is handled. I'm not sure if this handling needs to also be extended to exception codes with success codes in https://learn.microsoft.com/en-us/windows/win32/learnwin32/error-codes-in-com (based on the most significant bit of the 32-bit code)
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move safefetch handling into existing _M_ARM64 block

Suggestions for os_windows.cpp: 
- Merge the AMD64 block at line 2658 with the one at 2651.
- Move line 2656 `Thread* t = ...` to line 2680 as `t` seems not used until line 2681

Thanks

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

PR Review: https://git.openjdk.org/jdk/pull/27074#pullrequestreview-3199611624

From duke at openjdk.org  Tue Sep  9 06:48:11 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Sep 2025 06:48:11 GMT
Subject: RFR: 8367085: Sort os/posix includes
In-Reply-To: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
References: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
Message-ID: <Bdq3aYJCRLQ2zBn-WP9ogfKAiut8qWZykeyFIAwn4Ww=.fe6a62c8-ca78-4443-9ff3-bf7e4023eda4@github.com>

On Mon, 8 Sep 2025 10:54:54 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I sort includes in `os/posix` using `SortIncludes.java`.
> 
> Passes `tier1`.

@fandreuz 
Your change (at version 8c7f922aaada99c7e88cf35e14fe295cf2d82306) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27141#issuecomment-3269120860

From dholmes at openjdk.org  Tue Sep  9 06:52:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 06:52:17 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v4]
In-Reply-To: <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
Message-ID: <3mcftDRIvsUZRIayPdB0hvpnHIMGxVBMpoY71584NWw=.9414d332-5274-4f2d-a30e-219681938ba4@github.com>

On Mon, 8 Sep 2025 09:47:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/javaClasses.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26894#pullrequestreview-3199651986

From dholmes at openjdk.org  Tue Sep  9 07:21:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 07:21:19 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v3]
In-Reply-To: <_jo96ToBom5YqsnzX9NI1eG3oU8jUU9tYwcFIVpgiSA=.345f8d63-0aff-481a-8517-af8293e0e4ea@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <_jo96ToBom5YqsnzX9NI1eG3oU8jUU9tYwcFIVpgiSA=.345f8d63-0aff-481a-8517-af8293e0e4ea@github.com>
Message-ID: <WFbechvemOkTTqf9t9VkK2xCLTsaYi0vdCN3U5iZeu4=.c3580b56-1ef3-45b8-b54b-69b0c0855127@github.com>

On Mon, 8 Sep 2025 08:44:47 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
>> Specific casts are used to avoid UBSAN error.
>> 
>> Tests:
>> linux-x64-debug: tier1 passed
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset
>  - comments improved
>  - 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

That seems fine to me. Thanks

src/hotspot/share/cds/archiveBuilder.cpp line 1113:

> 1111:     address bottom = _builder->buffer_bottom();
> 1112:     address top = _builder->buffer_top();
> 1113:     // It is acceptable that new_bottom/new_top becomes zero.

Suggestion:

    // It is acceptable that new_bottom/new_top may be zero.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3199759902
PR Review Comment: https://git.openjdk.org/jdk/pull/26983#discussion_r2332272876

From jpai at openjdk.org  Tue Sep  9 07:25:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Sep 2025 07:25:10 GMT
Subject: RFR: 8367157: Remove jrunscript tool
Message-ID: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>

Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.

`jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.

tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

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

Commit messages:
 - remove tests for jrunscript
 - remove jrunscript implementation
 - remove references from tests
 - remove man page for jrunscript

Changes: https://git.openjdk.org/jdk/pull/27163/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367157
  Stats: 2364 lines in 24 files changed: 0 ins; 2360 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27163/head:pull/27163

PR: https://git.openjdk.org/jdk/pull/27163

From jsjolen at openjdk.org  Tue Sep  9 07:34:55 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 9 Sep 2025 07:34:55 GMT
Subject: Integrated: 8366363: MemBaseline accesses VMT without using lock
In-Reply-To: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
References: <EHr9P4Umy5YwrMVvcg7LOXp3Dp40jn2VZCAH1HiNxtU=.dc674737-8696-4d82-9852-3f1828320aa7@github.com>
Message-ID: <ir0hj1B3nEQq6VLhVWSt9yky8ht2YpytSHUEd_UCItU=.48b362cc-a635-48c7-a0ac-29cf0ea3620a@github.com>

On Fri, 29 Aug 2025 12:13:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead.

This pull request has now been integrated.

Changeset: ecfba66d
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecfba66d3d7c1fef755f0824f342189d0f231007
Stats:     229 lines in 12 files changed: 164 ins; 44 del; 21 mod

8366363: MemBaseline accesses VMT without using lock

Co-authored-by: Casper Norrbin <cnorrbin at openjdk.org>
Reviewed-by: azafari, cnorrbin

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

PR: https://git.openjdk.org/jdk/pull/27003

From dholmes at openjdk.org  Tue Sep  9 07:40:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Sep 2025 07:40:05 GMT
Subject: RFR: 8367085: Sort os/posix includes
In-Reply-To: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
References: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
Message-ID: <GeAY88GiDWq-bLh9p2WtTZiTV3qGKFg94b7gsQ3VzZc=.922e16f2-328f-4582-a609-2b080dc5b73c@github.com>

On Mon, 8 Sep 2025 10:54:54 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I sort includes in `os/posix` using `SortIncludes.java`.
> 
> Passes `tier1`.

Looks fine. Thanks

@fandreuz  again please wait for two reviews before trying to integrate. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27141#pullrequestreview-3199820263
PR Comment: https://git.openjdk.org/jdk/pull/27141#issuecomment-3269314650

From duke at openjdk.org  Tue Sep  9 07:40:06 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 9 Sep 2025 07:40:06 GMT
Subject: Integrated: 8367085: Sort os/posix includes
In-Reply-To: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
References: <RPUK_JqAO-uXJyKNzydwYBg3fruKMcj18sefKZm61fo=.ea03fc75-85ac-4128-8a36-2ebc1b81ac2a@github.com>
Message-ID: <spPzBczhX5dRMBDFFLCuYehAz6KVAOVQ2oiY3Fj7CpY=.3d91a301-cf20-44fd-a3a1-4618275da2ff@github.com>

On Mon, 8 Sep 2025 10:54:54 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I sort includes in `os/posix` using `SortIncludes.java`.
> 
> Passes `tier1`.

This pull request has now been integrated.

Changeset: 67bb22f3
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67bb22f3d661d7edf7a0949612d9fb64f0124cad
Stats:     32 lines in 8 files changed: 15 ins; 14 del; 3 mod

8367085: Sort os/posix includes

Reviewed-by: ayang, dholmes

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

PR: https://git.openjdk.org/jdk/pull/27141

From jpai at openjdk.org  Tue Sep  9 07:44:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Sep 2025 07:44:05 GMT
Subject: RFR: 8367157: Remove jrunscript tool
In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
Message-ID: <y3Jvq4duN88uQ5U5EfVdv3GWi672w20xfFSSepfp6LE=.d7d16a82-9745-4299-860b-2f2e68ca1a56@github.com>

On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
> 
> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
> 
> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

The CSR for this change is now ready for review https://bugs.openjdk.org/browse/JDK-8367229

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

PR Comment: https://git.openjdk.org/jdk/pull/27163#issuecomment-3269343064

From duke at openjdk.org  Tue Sep  9 08:01:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Sep 2025 08:01:22 GMT
Subject: RFR: 8364103: Convert existing sprintf-chains to stringStream [v4]
In-Reply-To: <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
 <wK2L5krHxfpaaJRwDT_pnyoXlkPWpjWBzyYzNKhDNqA=.ac0f0ef0-053c-460d-beb8-06ce26100366@github.com>
Message-ID: <aR7Qvq7TloDY5ufCWX2Zx2Mel7MnaMgNgjFJig_ggsA=.7725373a-e295-4d77-bba2-13a9ae9f6c1a@github.com>

On Mon, 8 Sep 2025 09:47:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
>> 
>> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
>> a) low-level nature of the code, and 
>> b) widespread usage of logging in the VM, 
>> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
>> 
>> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/javaClasses.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

@Arraying 
Your change (at version 2104919078762387b6c3eb7cc102900316717ec1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26894#issuecomment-3269402358

From phubner at openjdk.org  Tue Sep  9 09:05:27 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 9 Sep 2025 09:05:27 GMT
Subject: Integrated: 8364103: Convert existing sprintf-chains to stringStream
In-Reply-To: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
References: <xbbCS-TR5liWQKlJCsaDMsmLDZNuLIw54t9tCpphXTs=.78fc8a50-f39b-4253-8c10-9376ff25235b@github.com>
Message-ID: <CxZ7Um6WrNkBURp3YCTMibmluAxtWkifR0w7MjvhZ0U=.6ac52ac4-ad4d-48b0-9372-8e3767e43ca0@github.com>

On Fri, 22 Aug 2025 08:49:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR refactors `javaClasses`' `print_stack_element_to_stream` to use a `stringStream` instead of manually maintaining a buffer with `os::snprintf` chains.
> 
> The JBS issue outlines to do this for all occurrences of `snprintf`-like chains. The majority of the calls to `os::snprintf`, `os::snprintf_checked`, `os::vsnprintf`, etc. occur just once. `LogTagSet::vwrite` is the only place to my knowledge where there remains a `vsnprintf` chain using manual buffer arithmetic. After consulting @jdksjolen, we decided that due to the
> a) low-level nature of the code, and 
> b) widespread usage of logging in the VM, 
> this should probably warrant a larger discussion and/or separate issue. Personally, I feel like the performance & correctness risks of introducing a high-level abstraction here outweighs the benefits. 
> 
> I've run tests with JDK tiers 1-3 on macOS (AArch64, x64), Linux (AArch64, x64), and Windows (x64); all green.

This pull request has now been integrated.

Changeset: cfb80934
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfb809344c0205875b35991ce6807333df41c949
Stats:     48 lines in 1 file changed: 5 ins; 26 del; 17 mod

8364103: Convert existing sprintf-chains to stringStream

Reviewed-by: kbarrett, dholmes, iklam

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

PR: https://git.openjdk.org/jdk/pull/26894

From azafari at openjdk.org  Tue Sep  9 10:11:29 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 9 Sep 2025 10:11:29 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v2]
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <OP6vz5xXzIfT3HG6mvjeHx-C-ms71Dgciu5o2Ezzj3c=.cbb17056-34eb-49ea-991b-66fdb1cb9c0d@github.com>

> The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`.
> 
> Tests:
> tiers1-5, main platforms, debug/product

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - after merge with 8366363.
 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure

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

Changes: https://git.openjdk.org/jdk/pull/27137/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=01
  Stats: 226 lines in 13 files changed: 70 ins; 94 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/27137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27137/head:pull/27137

PR: https://git.openjdk.org/jdk/pull/27137

From azafari at openjdk.org  Tue Sep  9 10:34:20 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 9 Sep 2025 10:34:20 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v3]
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <jOVCZZ80vXD5M9nwHe22xhMcfbO3-Id0pkmZXiik0Bg=.ad1c36a5-8d02-4b7d-9197-e51efe965999@github.com>

> The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`.
> 
> Tests:
> tiers1-5, main platforms, debug/product

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - after merge with 8366363.
 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure

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

Changes: https://git.openjdk.org/jdk/pull/27137/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27137&range=02
  Stats: 209 lines in 12 files changed: 51 ins; 93 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/27137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27137/head:pull/27137

PR: https://git.openjdk.org/jdk/pull/27137

From cnorrbin at openjdk.org  Tue Sep  9 11:36:45 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 9 Sep 2025 11:36:45 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with exitValue
 = 134
Message-ID: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>

Hi everyone,

During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.

The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:

1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
3. immediately starts the async logging thread.

With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.

Testing:
- Oracle tiers 1-3
- Repeated runs of `StressAsyncUL.java` with no observed lock-ups

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

Commit messages:
 - init fix

Changes: https://git.openjdk.org/jdk/pull/27169/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27169&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362282
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27169/head:pull/27169

PR: https://git.openjdk.org/jdk/pull/27169

From alanb at openjdk.org  Tue Sep  9 12:47:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Sep 2025 12:47:29 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v9]
In-Reply-To: <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
Message-ID: <t9RxyjBi-PlR-KcLRJCh7a_k6biirGDLUysmGGoCv3A=.43fdca26-0fd1-4c99-904f-faa71115e850@github.com>

On Wed, 25 Jun 2025 08:18:19 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

Looks okay to me, thanks for moving away from the hardcoded root.

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 37:

> 35:  */
> 36: 
> 37: import java.io.File;

I assume this is a left-over from early iterations.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-3201363507
PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2333428827

From erikj at openjdk.org  Tue Sep  9 13:30:49 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 Sep 2025 13:30:49 GMT
Subject: RFR: 8367157: Remove jrunscript tool
In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com>
Message-ID: <LsTLMMH1k5DieFltepGzojjH1D6eDXWJoaAxOTAbYDs=.b2ffba69-25dc-48fa-aaa6-bb8b3f24b2fd@github.com>

On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157.
> 
> `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests.
> 
> tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3201606997

From jsikstro at openjdk.org  Tue Sep  9 16:46:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 9 Sep 2025 16:46:00 GMT
Subject: RFR: 8367268: Remove unused os::numa_topology_changed()
Message-ID: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>

Hello,

The method os::numa_topology_changed() returns false on all platforms with no callers. It makes sense to remove it as the JVM does not support changing the NUMA topology during runtime, or in other words, hotswapping CPUs. There are a lot of places that break if the NUMA topology would change during runtime.

The last implementation of os::numa_topology_changed() that did something other than just returning false was removed in [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224) with the removal of the Solaris and SPARC ports.

I do not see an issue with building on AIX, but would appreciate any feedback on this from AIX maintainers.

Testing:
 * Running through tier1 on Oracle supported platforms

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

Commit messages:
 - 8367268: Remove unused os::numa_topology_changed()

Changes: https://git.openjdk.org/jdk/pull/27176/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367268
  Stats: 10 lines in 5 files changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27176/head:pull/27176

PR: https://git.openjdk.org/jdk/pull/27176

From ayang at openjdk.org  Tue Sep  9 18:43:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 9 Sep 2025 18:43:49 GMT
Subject: RFR: 8367268: Remove unused os::numa_topology_changed()
In-Reply-To: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
References: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
Message-ID: <JMnDFKhrEfz8D0W_6_o4uOWvV3XlaFBsziGc75QvKJY=.7b05716d-a8d0-464b-908c-49a68d08082c@github.com>

On Tue, 9 Sep 2025 16:39:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The method os::numa_topology_changed() returns false on all platforms with no callers. It makes sense to remove it as the JVM does not support changing the NUMA topology during runtime, or in other words, hotswapping CPUs. There are a lot of places that break if the NUMA topology would change during runtime.
> 
> The last implementation of os::numa_topology_changed() that did something other than just returning false was removed in [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224) with the removal of the Solaris and SPARC ports.
> 
> I do not see an issue with building on AIX, but would appreciate any feedback on this from AIX maintainers.
> 
> Testing:
>  * Running through tier1 on Oracle supported platforms

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27176#pullrequestreview-3202819506

From dlong at openjdk.org  Wed Sep 10 01:09:16 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 10 Sep 2025 01:09:16 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3]
In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
Message-ID: <AwkHmH0d9__b_S9ycjrMsSJx1lSWIgekneIgiPb4PGM=.37491d2c-9b0b-4d84-88ef-f9555865445d@github.com>

On Tue, 2 Sep 2025 20:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert whitespace change
>  - undo debug changes
>  - cleanup

I need one more review for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3272844515

From duke at openjdk.org  Wed Sep 10 02:12:21 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Sep 2025 02:12:21 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v9]
In-Reply-To: <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <UFTh0Uj9S9GAIdGwa1HTvabGFiJQxDnOoTU_t7W1vAA=.f22ef8ad-0660-4693-9d41-141d99983a2f@github.com>
Message-ID: <59NBWS-Uafn1S0RrkdeuA59-kh0g36vTzUIkuftZZqE=.be9ad04e-d15c-4931-b5fb-dffd1bc754d4@github.com>

On Wed, 25 Jun 2025 08:18:19 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

@ktakakuri 
Your change (at version 3490e658a454a7fa6f6ddec506724278971e0f59) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-3272942966

From duke at openjdk.org  Wed Sep 10 02:52:51 2025
From: duke at openjdk.org (mazhen)
Date: Wed, 10 Sep 2025 02:52:51 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
 [v2]
In-Reply-To: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
Message-ID: <TDca9urtEMX7tjVgkFx9CYoz2GYxDKe817ZOKvGVOWc=.83b2249f-5332-4aee-869a-53dd2f20d89e@github.com>

> #### Summary
> 
> This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.
> 
> #### Problem
> 
> The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.
> 
> *   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
> *   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.
> 
> #### Solution
> 
> The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.
> 
> This change makes the test's logic robust and its behavior consistent across different environments.

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

  Restore TestStackGuardPagesNative to ProblemList as requested

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27114/files
  - new: https://git.openjdk.org/jdk/pull/27114/files/b688eaca..18ac75c7

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27114/head:pull/27114

PR: https://git.openjdk.org/jdk/pull/27114

From duke at openjdk.org  Wed Sep 10 03:00:13 2025
From: duke at openjdk.org (mazhen)
Date: Wed, 10 Sep 2025 03:00:13 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
 [v2]
In-Reply-To: <nmovWDUO5HeH6YtGqaYmRKTebEtPDOf86gprYef7eEc=.80243da6-2cf4-4134-b884-d5c47a17e654@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
 <nmovWDUO5HeH6YtGqaYmRKTebEtPDOf86gprYef7eEc=.80243da6-2cf4-4134-b884-d5c47a17e654@github.com>
Message-ID: <WZlHJMKXxYmfIu9ZPQ_UunBPqaR0iQmip3C2ECNHM_8=.b1b102be-b34c-4d7a-b809-419622a234b3@github.com>

On Mon, 8 Sep 2025 06:44:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> mazhen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore TestStackGuardPagesNative to ProblemList as requested
>
> test/hotspot/jtreg/ProblemList.txt line 109:
> 
>> 107: runtime/os/TestTracePageSizes.java#Parallel 8267460 linux-aarch64
>> 108: runtime/os/TestTracePageSizes.java#Serial 8267460 linux-aarch64
>> 109: runtime/StackGuardPages/TestStackGuardPagesNative.java 8303612 linux-all
> 
> You can't remove this from the ProblemList unless 8303612 is actually fixed.

Thank you for the approval and the clear instructions. I have now pushed the new commit that restores TestStackGuardPagesNative.java to the ProblemList

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27114#discussion_r2335381901

From dholmes at openjdk.org  Wed Sep 10 05:44:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 05:44:09 GMT
Subject: RFR: 8366938: Test runtime/handshake/HandshakeTimeoutTest.java crashed
Message-ID: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>

Please review this trivial test fix to restore the timeout to 480 as it would implicitly have been before the timeout-factor change.

Thanks

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

Commit messages:
 - 8366938: Test runtime/handshake/HandshakeTimeoutTest.java crashed

Changes: https://git.openjdk.org/jdk/pull/27183/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366938
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27183/head:pull/27183

PR: https://git.openjdk.org/jdk/pull/27183

From kbarrett at openjdk.org  Wed Sep 10 05:44:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 10 Sep 2025 05:44:10 GMT
Subject: RFR: 8366938: Test runtime/handshake/HandshakeTimeoutTest.java
 crashed
In-Reply-To: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>
References: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>
Message-ID: <weWfxVaMFLEYTSxICfm5FF1Roo3ewxkxR0p_t8k5thw=.0ec4e7a0-72b3-4ff3-a938-006231f63f5b@github.com>

On Wed, 10 Sep 2025 05:32:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial test fix to restore the timeout to 480 as it would implicitly have been before the timeout-factor change.
> 
> Thanks

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27183#pullrequestreview-3204497188

From dholmes at openjdk.org  Wed Sep 10 05:50:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 05:50:19 GMT
Subject: RFR: 8366938: Test runtime/handshake/HandshakeTimeoutTest.java
 crashed
In-Reply-To: <weWfxVaMFLEYTSxICfm5FF1Roo3ewxkxR0p_t8k5thw=.0ec4e7a0-72b3-4ff3-a938-006231f63f5b@github.com>
References: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>
 <weWfxVaMFLEYTSxICfm5FF1Roo3ewxkxR0p_t8k5thw=.0ec4e7a0-72b3-4ff3-a938-006231f63f5b@github.com>
Message-ID: <KnFO4TqS_s0LqALUolC_aQn5uvu7nfJhQCv3jpnE-jI=.11588a5a-f9ea-42c6-870e-d5f9da1e5b98@github.com>

On Wed, 10 Sep 2025 05:37:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this trivial test fix to restore the timeout to 480 as it would implicitly have been before the timeout-factor change.
>> 
>> Thanks
>
> Looks good, and trivial.

Thanks @kimbarrett !

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

PR Comment: https://git.openjdk.org/jdk/pull/27183#issuecomment-3273399720

From dholmes at openjdk.org  Wed Sep 10 05:50:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 05:50:20 GMT
Subject: Integrated: 8366938: Test runtime/handshake/HandshakeTimeoutTest.java
 crashed
In-Reply-To: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>
References: <2SMBFZeqPp3r50W0mAsdLaM5GCKG9gSI7pKBfKmSKmA=.780918fe-4c44-43ea-aca6-89f508516494@github.com>
Message-ID: <46cb9uAzVIDFd1Dn8gbbMpp-XRnl6CuyQQ57O7MYN60=.5a994633-24ed-4bdc-8bc4-be63b93460a6@github.com>

On Wed, 10 Sep 2025 05:32:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial test fix to restore the timeout to 480 as it would implicitly have been before the timeout-factor change.
> 
> Thanks

This pull request has now been integrated.

Changeset: 8ab8d02e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ab8d02e40e987a5eb5e8036ff4f12146ac2b16a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8366938: Test runtime/handshake/HandshakeTimeoutTest.java crashed

Reviewed-by: kbarrett

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

PR: https://git.openjdk.org/jdk/pull/27183

From ktakakuri at openjdk.org  Wed Sep 10 06:40:26 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Wed, 10 Sep 2025 06:40:26 GMT
Subject: Integrated: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform
In-Reply-To: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
Message-ID: <FNO1bzMwL324PfNsvA6yQTQql4hP3Uojsw1-dKAWg4o=.7226ffb9-9d79-4a8c-b64c-7144a32fc173@github.com>

On Mon, 10 Feb 2025 06:18:42 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
> After this fix, I verified that the test passed.
> 
> https://github.com/openjdk/jdk/pull/22142
> I refer to this fix.
> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 9e3fa321
Author:    Kazuhisa Takakuri <ktakakuri at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e3fa3216fd4ebd73da6e003a7b767cf001a1169
Stats:     18 lines in 1 file changed: 17 ins; 0 del; 1 mod

8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

Reviewed-by: dholmes, alanb

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

PR: https://git.openjdk.org/jdk/pull/23536

From dholmes at openjdk.org  Wed Sep 10 06:45:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 06:45:12 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134
In-Reply-To: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
Message-ID: <mH7bIW_uOv_0xwudNdXm-ZV_FgpV8tkVBKQFuk2Zt1U=.2e7050a7-2c22-4bc4-84a6-f28b30888990@github.com>

On Tue, 9 Sep 2025 11:28:41 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
> 
> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
> 
> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
> 3. immediately starts the async logging thread.
> 
> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
> 
> Testing:
> - Oracle tiers 1-3
> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups

Fix looks good. One minor nit. Thanks.

src/hotspot/share/logging/logAsyncWriter.cpp line 323:

> 321:     // We use LogOutputList's RCU counters to ensure all synchronous logsites have completed.
> 322:     // After that, we publish the initalized _instance to readers.
> 323:     // Then, start the AsyncLog Thread; It exclusively takes over all logging I/O.

Suggestion:

    // Then we start the AsyncLog Thread and it exclusively takes over all logging I/O.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27169#pullrequestreview-3204635598
PR Review Comment: https://git.openjdk.org/jdk/pull/27169#discussion_r2335715647

From dholmes at openjdk.org  Wed Sep 10 07:12:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 07:12:20 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
 [v2]
In-Reply-To: <TDca9urtEMX7tjVgkFx9CYoz2GYxDKe817ZOKvGVOWc=.83b2249f-5332-4aee-869a-53dd2f20d89e@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
 <TDca9urtEMX7tjVgkFx9CYoz2GYxDKe817ZOKvGVOWc=.83b2249f-5332-4aee-869a-53dd2f20d89e@github.com>
Message-ID: <pBA3dL6USfXaXy07NRJw--YClskoyaQBPWoXyfcJrVQ=.099177a3-3e53-4e90-980a-f6133d198978@github.com>

On Wed, 10 Sep 2025 02:52:51 GMT, mazhen <duke at openjdk.org> wrote:

>> #### Summary
>> 
>> This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.
>> 
>> #### Problem
>> 
>> The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.
>> 
>> *   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
>> *   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.
>> 
>> #### Solution
>> 
>> The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.
>> 
>> This change makes the test's logic robust and its behavior consistent across different environments.
>
> mazhen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore TestStackGuardPagesNative to ProblemList as requested

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27114#pullrequestreview-3204733003

From dholmes at openjdk.org  Wed Sep 10 07:17:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 07:17:19 GMT
Subject: RFR: 8367268: Remove unused os::numa_topology_changed()
In-Reply-To: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
References: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
Message-ID: <YlIcJA_C4VIilPL38gXUvy9uNdHxFunY6dsIkgijqKU=.a4f8adc8-98f3-46b8-afaa-029d1619d313@github.com>

On Tue, 9 Sep 2025 16:39:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The method os::numa_topology_changed() returns false on all platforms with no callers. It makes sense to remove it as the JVM does not support changing the NUMA topology during runtime, or in other words, hotswapping CPUs. There are a lot of places that break if the NUMA topology would change during runtime.
> 
> The last implementation of os::numa_topology_changed() that did something other than just returning false was removed in [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224) with the removal of the Solaris and SPARC ports.
> 
> I do not see an issue with building on AIX, but would appreciate any feedback on this from AIX maintainers.
> 
> Testing:
>  * Running through tier1 on Oracle supported platforms

Nice cleanup. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27176#pullrequestreview-3204754695

From jsjolen at openjdk.org  Wed Sep 10 07:24:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 10 Sep 2025 07:24:10 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134
In-Reply-To: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
Message-ID: <GAPHWdDsiDgJs1FAWy7PZP3KxCGPaXHego13U215Qcg=.8b2d1e9c-77e5-4529-9711-8d6e825015d7@github.com>

On Tue, 9 Sep 2025 11:28:41 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
> 
> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
> 
> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
> 3. immediately starts the async logging thread.
> 
> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
> 
> Testing:
> - Oracle tiers 1-3
> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups

Seems correct

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27169#pullrequestreview-3204794949

From cnorrbin at openjdk.org  Wed Sep 10 08:03:17 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 10 Sep 2025 08:03:17 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134 [v2]
In-Reply-To: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
Message-ID: <KD7PYrIiSa2-OxMWkRKJDr1p3oOa7aVjWXxyAwQ-_LM=.d8f0cd10-4e8e-4434-8f2c-aa9a79d49f76@github.com>

> Hi everyone,
> 
> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
> 
> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
> 
> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
> 3. immediately starts the async logging thread.
> 
> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
> 
> Testing:
> - Oracle tiers 1-3
> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  changed comment wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27169/files
  - new: https://git.openjdk.org/jdk/pull/27169/files/d8dd6162..8e42198b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27169/head:pull/27169

PR: https://git.openjdk.org/jdk/pull/27169

From cnorrbin at openjdk.org  Wed Sep 10 08:03:19 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 10 Sep 2025 08:03:19 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134 [v2]
In-Reply-To: <mH7bIW_uOv_0xwudNdXm-ZV_FgpV8tkVBKQFuk2Zt1U=.2e7050a7-2c22-4bc4-84a6-f28b30888990@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
 <mH7bIW_uOv_0xwudNdXm-ZV_FgpV8tkVBKQFuk2Zt1U=.2e7050a7-2c22-4bc4-84a6-f28b30888990@github.com>
Message-ID: <OQoS575OFQ91yU4vwvQSBVVdq3dqJKyQ1dAQjl_fNdo=.6e13b4d3-8cd9-4d8d-8986-9f09a82f407c@github.com>

On Wed, 10 Sep 2025 06:42:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed comment wording
>
> src/hotspot/share/logging/logAsyncWriter.cpp line 323:
> 
>> 321:     // We use LogOutputList's RCU counters to ensure all synchronous logsites have completed.
>> 322:     // After that, we publish the initalized _instance to readers.
>> 323:     // Then, start the AsyncLog Thread; It exclusively takes over all logging I/O.
> 
> Suggestion:
> 
>     // Then we start the AsyncLog Thread and it exclusively takes over all logging I/O.

Changed wording to this in 8e42198.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27169#discussion_r2335910978

From jsjolen at openjdk.org  Wed Sep 10 08:13:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 10 Sep 2025 08:13:05 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134 [v2]
In-Reply-To: <KD7PYrIiSa2-OxMWkRKJDr1p3oOa7aVjWXxyAwQ-_LM=.d8f0cd10-4e8e-4434-8f2c-aa9a79d49f76@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
 <KD7PYrIiSa2-OxMWkRKJDr1p3oOa7aVjWXxyAwQ-_LM=.d8f0cd10-4e8e-4434-8f2c-aa9a79d49f76@github.com>
Message-ID: <B1CWEUDPp6atkuTlCXHUW_F-_icAVtvwkfvkrm9aeyc=.3d6ce400-b956-4176-a580-14719b4f5ccb@github.com>

On Wed, 10 Sep 2025 08:03:17 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
>> 
>> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
>> 
>> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
>> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
>> 3. immediately starts the async logging thread.
>> 
>> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
>> 
>> Testing:
>> - Oracle tiers 1-3
>> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed comment wording

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27169#pullrequestreview-3204980196

From dholmes at openjdk.org  Wed Sep 10 08:19:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 08:19:08 GMT
Subject: RFR: 8367309: Test runtime/os/windows/TestAvailableProcessors.java
 fails to compile after mis-merge
Message-ID: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>

Restored the deleted imports. Removed an unneeded import.

Thanks

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

Commit messages:
 - 8367309: Test runtime/os/windows/TestAvailableProcessors.java fails to compile after mis-merge

Changes: https://git.openjdk.org/jdk/pull/27186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367309
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27186/head:pull/27186

PR: https://git.openjdk.org/jdk/pull/27186

From shade at openjdk.org  Wed Sep 10 08:19:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Sep 2025 08:19:08 GMT
Subject: RFR: 8367309: Test runtime/os/windows/TestAvailableProcessors.java
 fails to compile after mis-merge
In-Reply-To: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
References: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
Message-ID: <VVAe85NxxGGq3b2H9X67rrfDb1o5b3v4Syl5cNS1iiY=.bb4f28ad-43d3-4279-a2f8-e25f4e0a1f23@github.com>

On Wed, 10 Sep 2025 08:05:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Restored the deleted imports. Removed an unneeded import.
> 
> Thanks

Looks fine and trivial, assuming the test works.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27186#pullrequestreview-3204995276

From dholmes at openjdk.org  Wed Sep 10 08:19:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 08:19:09 GMT
Subject: RFR: 8367309: Test runtime/os/windows/TestAvailableProcessors.java
 fails to compile after mis-merge
In-Reply-To: <VVAe85NxxGGq3b2H9X67rrfDb1o5b3v4Syl5cNS1iiY=.bb4f28ad-43d3-4279-a2f8-e25f4e0a1f23@github.com>
References: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
 <VVAe85NxxGGq3b2H9X67rrfDb1o5b3v4Syl5cNS1iiY=.bb4f28ad-43d3-4279-a2f8-e25f4e0a1f23@github.com>
Message-ID: <IZzoSOGzm9cchkKwxNdHmzep6UZka7T6AxWc7S3hLKI=.872d00b8-5416-4194-935b-5072bd889e10@github.com>

On Wed, 10 Sep 2025 08:13:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Restored the deleted imports. Removed an unneeded import.
>> 
>> Thanks
>
> Looks fine and trivial, assuming the test works.

Thanks @shipilev  - just waiting for test runs to complete

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

PR Comment: https://git.openjdk.org/jdk/pull/27186#issuecomment-3273835021

From alanb at openjdk.org  Wed Sep 10 08:32:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Sep 2025 08:32:54 GMT
Subject: RFR: 8367309: Test runtime/os/windows/TestAvailableProcessors.java
 fails to compile after mis-merge
In-Reply-To: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
References: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
Message-ID: <BwHUrtrexGWswqu1GKcmMHZSaGb03CNpIVZM-hUZOwQ=.b9f1c098-c334-4c61-92c2-62d07c374b31@github.com>

On Wed, 10 Sep 2025 08:05:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Restored the deleted imports. Removed an unneeded import.
> 
> Thanks

Unfortunate that PR 23536 integrated when it was >2000 commits behind main line.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27186#pullrequestreview-3205061510

From dholmes at openjdk.org  Wed Sep 10 08:39:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 08:39:37 GMT
Subject: RFR: 8367309: Test runtime/os/windows/TestAvailableProcessors.java
 fails to compile after mis-merge
In-Reply-To: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
References: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
Message-ID: <AA5zkhojwkkDCNUpw0TmAsnbJfmcu-Zdqq3U5MHfrCY=.848a52d8-761c-4723-962a-ee8c754ed701@github.com>

On Wed, 10 Sep 2025 08:05:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Restored the deleted imports. Removed an unneeded import.
> 
> Thanks

Thanks Alan. Yes mea culpa for allowing that. I mistakenly assumed that git would not auto-merge if that one file had been changed by another commit!

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

PR Comment: https://git.openjdk.org/jdk/pull/27186#issuecomment-3273918305

From dholmes at openjdk.org  Wed Sep 10 08:50:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 08:50:16 GMT
Subject: Integrated: 8367309: Test
 runtime/os/windows/TestAvailableProcessors.java fails to compile after
 mis-merge
In-Reply-To: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
References: <88d8V47sXLYTi-LUAcedfAr1zyFntH4lD8iz3_IPpu4=.053d5f23-c07e-4017-bc8f-092606a9ea68@github.com>
Message-ID: <nDKCAqY77ZwyvLTf6AG946tQ16MgrUlcz2Kq3b92SXE=.26b8681b-43c8-4eb9-9793-3b3192a93029@github.com>

On Wed, 10 Sep 2025 08:05:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Restored the deleted imports. Removed an unneeded import.
> 
> Thanks

This pull request has now been integrated.

Changeset: f3de3862
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3de386263e16e33c2812706cf41410da2cd58c6
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8367309: Test runtime/os/windows/TestAvailableProcessors.java fails to compile after mis-merge

Reviewed-by: shade, alanb

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

PR: https://git.openjdk.org/jdk/pull/27186

From dnsimon at openjdk.org  Wed Sep 10 10:02:25 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 10 Sep 2025 10:02:25 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v7]
In-Reply-To: <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
Message-ID: <CU5wkudYTN8BHF25DUPuGsog9iFcHLuxaO-_xFwrcT0=.3d2b2838-330b-4883-8d35-9988b9434556@github.com>

On Fri, 17 Mar 2023 15:58:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Style fixes
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Style fixes
>  - SA and JVMCI fixes
>  - Fixes includes and style
>  - SA additional caching from Chris Plummer
>  - Addressing comments from first reviews
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Reimplementation of FieldInfo as an unsigned5 stream

One side-effect of this change is that verifying certain old classes (think JCK) can take a long time. For example:

Test.java:

import java.lang.classfile.ClassFile;
import java.lang.constant.ClassDesc;
import static java.lang.constant.ConstantDescs.CD_int;

public class Test {
    public static void main(String[] args) throws Exception {
        int numberOfFields = 65_000;
        ClassDesc classDesc = ClassDesc.of("ManyFieldsClass");

        byte[] classfile = ClassFile.of().build(classDesc, classBuilder -> {
            int flags = ClassFile.ACC_STATIC | ClassFile.ACC_PUBLIC;
            classBuilder.withVersion(ClassFile.JAVA_5_VERSION, 0);
            classBuilder.withField("myField0", CD_int, flags);
            for (int i = 1; i < numberOfFields; i++) {
                classBuilder.withField("myField" + i, CD_int, flags);
            }
        });

        ClassLoader cl = new ClassLoader() {
            @Override
            protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
                if (name.equals("ManyFieldsClass")) {
                    return defineClass(name, classfile, 0, classfile.length);
                }
                return super.loadClass(name, resolve);
            }
        };

        long start = System.currentTimeMillis();
        var c = Class.forName("ManyFieldsClass", true, cl);
        System.out.printf("took %,d ms to load %s%n", (System.currentTimeMillis() - start), c);
    }
}



> java Test.java
took 19,854 ms to load class ManyFieldsClass


Probably not worth worrying about - just wanted to point out something I hit while processing the JCK with Native Image.

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

PR Comment: https://git.openjdk.org/jdk/pull/12855#issuecomment-3274222505

From cnorrbin at openjdk.org  Wed Sep 10 13:49:35 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 10 Sep 2025 13:49:35 GMT
Subject: RFR: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134 [v2]
In-Reply-To: <KD7PYrIiSa2-OxMWkRKJDr1p3oOa7aVjWXxyAwQ-_LM=.d8f0cd10-4e8e-4434-8f2c-aa9a79d49f76@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
 <KD7PYrIiSa2-OxMWkRKJDr1p3oOa7aVjWXxyAwQ-_LM=.d8f0cd10-4e8e-4434-8f2c-aa9a79d49f76@github.com>
Message-ID: <9105-lhIxZ_RRL5WEJxi9zQ3OPDgxouqdhskyRog6ck=.e01c4635-9dac-4f0c-8c66-fff008d2dec0@github.com>

On Wed, 10 Sep 2025 08:03:17 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
>> 
>> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
>> 
>> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
>> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
>> 3. immediately starts the async logging thread.
>> 
>> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
>> 
>> Testing:
>> - Oracle tiers 1-3
>> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed comment wording

Thank you for the quick reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27169#issuecomment-3275044855

From cnorrbin at openjdk.org  Wed Sep 10 13:49:37 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 10 Sep 2025 13:49:37 GMT
Subject: Integrated: 8362282: runtime/logging/StressAsyncUL.java failed with
 exitValue = 134
In-Reply-To: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
References: <bTF1pJ2YT1TXwYlsP9HQA9cTUlYA9CY-2UOjN22MtgI=.4453e213-1900-4a27-8df9-01dd70bcbae7@github.com>
Message-ID: <Qy8Y92EfouvyH0XJjBJ9Ia7mfPvtJ7VUSF0bp0gh8rQ=.ff675c0d-57cc-46c2-b6d7-291b4c033edd@github.com>

On Tue, 9 Sep 2025 11:28:41 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn?t yet running, producers could end up waiting for a consumer that didn?t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
> 
> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
> 
> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
> 3. immediately starts the async logging thread.
> 
> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
> 
> Testing:
> - Oracle tiers 1-3
> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups

This pull request has now been integrated.

Changeset: c968a672
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c968a672c034fe533ea5f4ac5efe37ffb76c93e2
Stats:     5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8362282: runtime/logging/StressAsyncUL.java failed with exitValue = 134

Reviewed-by: jsjolen, dholmes

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

PR: https://git.openjdk.org/jdk/pull/27169

From mbaesken at openjdk.org  Wed Sep 10 14:15:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Sep 2025 14:15:42 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v3]
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <HD8Sj-0FCpKlqt-BuiYvsMZKycCuQz_pmWrz93Y07J4=.e23a5102-5ecd-41cf-89c4-33d9700a5a1e@github.com>

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - merge aotMetaspace.cpp
 - Merge remote-tracking branch 'origin/master' into JDK-8359423
 - Adjust log message in metaspaceShared
 - JDK-8359423

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

Changes: https://git.openjdk.org/jdk/pull/25846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=02
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846

PR: https://git.openjdk.org/jdk/pull/25846

From jsjolen at openjdk.org  Wed Sep 10 15:45:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 10 Sep 2025 15:45:08 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing out
Message-ID: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>

Hi,

This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).

This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.

The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

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

Commit messages:
 - Change to debug

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

PR: https://git.openjdk.org/jdk/pull/27195

From ayang at openjdk.org  Wed Sep 10 15:49:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Sep 2025 15:49:32 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <1FThK9EJqzgcuWQ-66JJE-Nl4sGbY8KRPTAds47DVMw=.86bab00c-ec0d-43d2-88a9-b7a12e8f7d72@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

Makes sense; I also wonder if `trace`-level log can be reduced a bit -- the current amount is not very usable, IMO.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27195#pullrequestreview-3206783944

From lkorinth at openjdk.org  Wed Sep 10 16:01:40 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 10 Sep 2025 16:01:40 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <SCivSmWK2OMssyOEoxmpiybd5OUs2nONr0J3XQeWu7k=.afd0b6ec-d69a-4e5b-b0a2-c12946f920bd@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

Looks good to me!

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27195#pullrequestreview-3206829188

From dholmes at openjdk.org  Wed Sep 10 21:41:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 21:41:43 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <rOJ07m_-9L8KOmLUfgcPXuGtHVpNQS8UwjiT86JrHbs=.ae8826bb-ff00-4858-aa13-bf96f58775a8@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

Good fix. There's always a risk that "all" logging will reach a point where we get swamped with output, and that happened with AOT trace level.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27195#pullrequestreview-3207925885

From syan at openjdk.org  Thu Sep 11 06:07:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 06:07:40 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <HCyJS2TvXYpBkTwSeXBqRvUBzbk0Aco7V4Mdoke7puk=.f0cf8c48-8318-4a3d-8c3c-28a7a4b684e3@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27195#pullrequestreview-3209015223

From syan at openjdk.org  Thu Sep 11 06:52:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 06:52:29 GMT
Subject: RFR: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
 [v2]
In-Reply-To: <TDca9urtEMX7tjVgkFx9CYoz2GYxDKe817ZOKvGVOWc=.83b2249f-5332-4aee-869a-53dd2f20d89e@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
 <TDca9urtEMX7tjVgkFx9CYoz2GYxDKe817ZOKvGVOWc=.83b2249f-5332-4aee-869a-53dd2f20d89e@github.com>
Message-ID: <VwOWm-fskjxtvnQ9jz15_7xHYziFoYNaOhHSI7WMlW4=.9b8c5efe-1494-4063-9a6b-06d46102ce83@github.com>

On Wed, 10 Sep 2025 02:52:51 GMT, mazhen <duke at openjdk.org> wrote:

>> #### Summary
>> 
>> This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.
>> 
>> #### Problem
>> 
>> The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.
>> 
>> *   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
>> *   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.
>> 
>> #### Solution
>> 
>> The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.
>> 
>> This change makes the test's logic robust and its behavior consistent across different environments.
>
> mazhen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore TestStackGuardPagesNative to ProblemList as requested

GHA report test java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id0 timed out on macos-aarch64. I think it's unrelated to this PR.

I have create a [issue](https://bugs.openjdk.org/browse/JDK-8367395) to record it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27114#issuecomment-3278550388

From jsjolen at openjdk.org  Thu Sep 11 07:45:28 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 11 Sep 2025 07:45:28 GMT
Subject: RFR: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <e0S2V3NNBWtvI71enAk8ViSU8h_L-RpGeVXJoAhuYlU=.c3f8b03b-d7a5-436e-bc4c-0bd69481e554@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27195#issuecomment-3278933523

From jsjolen at openjdk.org  Thu Sep 11 07:45:29 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 11 Sep 2025 07:45:29 GMT
Subject: Integrated: 8366951: Test runtime/logging/StressAsyncUL.java is timing
 out
In-Reply-To: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
References: <LnWEIy6gCt6h2FbH3r3I69g86leEROrZqDTKeiZwiaY=.037e642b-f6ec-4f32-b186-67f3bdc92042@github.com>
Message-ID: <qxnS_WK-3X6TNco7ADB55vywnHnM8m79qVl72l6vAJk=.27c3fdf5-19de-43d4-b1d3-495a4d141e2b@github.com>

On Wed, 10 Sep 2025 15:36:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This test times out sometimes. This has been known to be caused previously by a resource-constrained execution environment. It may also be because of a race between async logging initialization and the loggers (see JDK-8362282).
> 
> This PR reduces the stress by changing the log level from `trace` to `debug`. This changes the amount of logging from 48M to 6.6M, a significant reduction.
> 
> The goal with the test was to find out if there are any bugs in the stalling mode by running it in a 'stressful' situation over a long time. The stalling mode was integrated in 2025-02-26 (see https://github.com/openjdk/jdk/pull/22770 ). I therefore believe that relaxing this test is in our interest, as it reduces the stress on our CICD infra.

This pull request has now been integrated.

Changeset: 8ba0db0d
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ba0db0de8b79f64cbfa56683f660f888c880182
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8366951: Test runtime/logging/StressAsyncUL.java is timing out

Reviewed-by: ayang, lkorinth, dholmes, syan

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

PR: https://git.openjdk.org/jdk/pull/27195

From mbaesken at openjdk.org  Thu Sep 11 07:50:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Sep 2025 07:50:07 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v4]
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <BO6YSyvQYrz8qVDWf2atMLd2p91bg2656M2UAx9vz4w=.810af716-2bfa-486b-9ed6-2e5712d9f915@github.com>

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust message in aotMetaspace and make it fit to the runtime/cds/appcds tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25846/files
  - new: https://git.openjdk.org/jdk/pull/25846/files/42901155..11b92d15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846

PR: https://git.openjdk.org/jdk/pull/25846

From jsikstro at openjdk.org  Thu Sep 11 08:56:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 08:56:55 GMT
Subject: RFR: 8367268: Remove unused os::numa_topology_changed() [v2]
In-Reply-To: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
References: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
Message-ID: <Nn3_5pkLi-uSDUuRAOA2g9Iqb0PLdHQT_zdSuV6DtSY=.92eff839-ad03-41b0-9bc4-24afc2944382@github.com>

> Hello,
> 
> The method os::numa_topology_changed() returns false on all platforms with no callers. It makes sense to remove it as the JVM does not support changing the NUMA topology during runtime, or in other words, hotswapping CPUs. There are a lot of places that break if the NUMA topology would change during runtime.
> 
> The last implementation of os::numa_topology_changed() that did something other than just returning false was removed in [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224) with the removal of the Solaris and SPARC ports.
> 
> I do not see an issue with building on AIX, but would appreciate any feedback on this from AIX maintainers.
> 
> Testing:
>  * tier1 on Oracle supported platforms

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8367268_numa_topology_changed
 - 8367268: Remove unused os::numa_topology_changed()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27176/files
  - new: https://git.openjdk.org/jdk/pull/27176/files/7205d735..0afe7aa4

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

  Stats: 6187 lines in 171 files changed: 3564 ins; 2005 del; 618 mod
  Patch: https://git.openjdk.org/jdk/pull/27176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27176/head:pull/27176

PR: https://git.openjdk.org/jdk/pull/27176

From jsikstro at openjdk.org  Thu Sep 11 08:56:56 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 08:56:56 GMT
Subject: RFR: 8367268: Remove unused os::numa_topology_changed() [v2]
In-Reply-To: <JMnDFKhrEfz8D0W_6_o4uOWvV3XlaFBsziGc75QvKJY=.7b05716d-a8d0-464b-908c-49a68d08082c@github.com>
References: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
 <JMnDFKhrEfz8D0W_6_o4uOWvV3XlaFBsziGc75QvKJY=.7b05716d-a8d0-464b-908c-49a68d08082c@github.com>
Message-ID: <hhtyUUwMuWvWPCSg21MeoIw81bCj66lRxD0NtWsykWY=.60f6f464-124a-455c-b4a4-e10684481c36@github.com>

On Tue, 9 Sep 2025 18:40:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8367268_numa_topology_changed
>>  - 8367268: Remove unused os::numa_topology_changed()
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews @albertnetymk and @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/27176#issuecomment-3279266755

From jsikstro at openjdk.org  Thu Sep 11 08:56:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 08:56:58 GMT
Subject: Integrated: 8367268: Remove unused os::numa_topology_changed()
In-Reply-To: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
References: <bSPaMw99ioYKbXpQ3Z5PuUdNr534wp_rpI3joNKyRkA=.af1c4bc4-5b62-4ae2-a22d-e5b0f1c0543d@github.com>
Message-ID: <iOXd0L-VxqihfVlZ_qn86ujPWyblACRYzy7bdgR491g=.7df76cfd-8b6c-40b9-84f2-97b84bc3b3a9@github.com>

On Tue, 9 Sep 2025 16:39:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The method os::numa_topology_changed() returns false on all platforms with no callers. It makes sense to remove it as the JVM does not support changing the NUMA topology during runtime, or in other words, hotswapping CPUs. There are a lot of places that break if the NUMA topology would change during runtime.
> 
> The last implementation of os::numa_topology_changed() that did something other than just returning false was removed in [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224) with the removal of the Solaris and SPARC ports.
> 
> I do not see an issue with building on AIX, but would appreciate any feedback on this from AIX maintainers.
> 
> Testing:
>  * tier1 on Oracle supported platforms

This pull request has now been integrated.

Changeset: 3d679087
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d679087b0376c221d536780cee387dc2dd8019e
Stats:     10 lines in 5 files changed: 0 ins; 10 del; 0 mod

8367268: Remove unused os::numa_topology_changed()

Reviewed-by: ayang, dholmes

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

PR: https://git.openjdk.org/jdk/pull/27176

From cnorrbin at openjdk.org  Thu Sep 11 09:47:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 11 Sep 2025 09:47:44 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive red-black
 tree
Message-ID: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>

Hi everyone,

Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance.

This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. 

Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead.

Testing:
- Oracle tiers 1-8

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

Commit messages:
 - moved blocktree tree logic to intrusive rbtree

Changes: https://git.openjdk.org/jdk/pull/27212/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367332
  Stats: 380 lines in 3 files changed: 35 ins; 290 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/27212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27212/head:pull/27212

PR: https://git.openjdk.org/jdk/pull/27212

From cnorrbin at openjdk.org  Thu Sep 11 09:52:48 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 11 Sep 2025 09:52:48 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive
 red-black tree
In-Reply-To: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
References: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
Message-ID: <NrfnXPLyh5Xq8LTSn8McL3MUbvUXT8DJy78D2p-hDjo=.9c1a45f8-d2cd-40ac-ada3-4385f0458474@github.com>

On Thu, 11 Sep 2025 09:40:21 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance.
> 
> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. 
> 
> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead.
> 
> Testing:
> - Oracle tiers 1-8

src/hotspot/share/memory/metaspace/blockTree.hpp line 59:

> 57: //           +-----+         +-----+
> 58: //           | 80  |         | 120 |
> 59: //           +-----+         +-----+

Small note: This extra node was added to the ascii tree since without it the tree isn't a valid red-black tree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27212#discussion_r2339847969

From jsjolen at openjdk.org  Thu Sep 11 10:14:50 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 11 Sep 2025 10:14:50 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
Message-ID: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>

Hi,

This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.

Passes tier1.

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

Commit messages:
 - Missing locks
 - Fix
 - Fix
 - Add missing locks

Changes: https://git.openjdk.org/jdk/pull/27038/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366658
  Stats: 53 lines in 8 files changed: 27 ins; 1 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/27038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27038/head:pull/27038

PR: https://git.openjdk.org/jdk/pull/27038

From jsjolen at openjdk.org  Thu Sep 11 10:14:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 11 Sep 2025 10:14:53 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <AHTxm1SV6IWbcwnfj7po-R8WvhrM0ui4K0Rf22P3HAE=.f457b1a7-5b33-47f3-98ca-739b906cb80d@github.com>

On Tue, 2 Sep 2025 07:07:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

src/hotspot/share/nmt/memTracker.hpp line 182:

> 180:     return VirtualMemoryTracker::Instance::walk_virtual_memory(walker);
> 181:   }
> 182: 

Added this so that we can do the usual checks and lock taking in the place where we typically take the lock.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 221:

> 219:   });
> 220:   return ret;
> 221: }

A VirtualMemoryWalker returned true or false depending on whether or not its operation succeeded, and we are meant to pass that along as the return value of walk_virtual_memory. That was missing, now fixed.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 349:

> 347: public:
> 348:   virtual bool do_allocation_site(const ReservedMemoryRegion* rgn) { return false; }
> 349: };

Indentation fix

test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 63:

> 61:   LOG("In reserved region " PTR_FORMAT ", size %X:", p2i(rmr.base()), rmr.size());
> 62:   vmt.tree()->visit_committed_regions(rmr, [&](CommittedMemoryRegion& region) {
> 63:     LOG("   committed region: " PTR_FORMAT ", size %X", p2i(region.base()), region.size());

Here the VMT was passed along but never actually used for printing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2321147605
PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2321146800
PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2321143077
PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2321144236

From mbaesken at openjdk.org  Thu Sep 11 12:00:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Sep 2025 12:00:33 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v5]
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Fix message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25846/files
  - new: https://git.openjdk.org/jdk/pull/25846/files/11b92d15..5784207f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846

PR: https://git.openjdk.org/jdk/pull/25846

From mbaesken at openjdk.org  Thu Sep 11 12:19:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Sep 2025 12:19:59 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v5]
In-Reply-To: <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>
Message-ID: <n4ick4B3MTu7b1tZxmpwuvQcWSCk9Y-pYHjaoGGHeP8=.8bd5704e-0dd5-4102-b335-cb4480af5003@github.com>

On Thu, 11 Sep 2025 12:00:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

I added the message passed to  `AOTMetaspace::unrecoverable_loading_error(const char* message)`  to the vm_exit output and also slightly adjusted the output so that it still fits to the `runtime/cds/appcds` tests .

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

PR Comment: https://git.openjdk.org/jdk/pull/25846#issuecomment-3280309555

From mbaesken at openjdk.org  Thu Sep 11 12:20:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Sep 2025 12:20:02 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v5]
In-Reply-To: <wvsxFPhtAfov_kmaX7vFbIv8y_5FS0G5rZXJzqlkGVE=.4ba09c65-4b5b-4706-80df-8595d409c345@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <wvsxFPhtAfov_kmaX7vFbIv8y_5FS0G5rZXJzqlkGVE=.4ba09c65-4b5b-4706-80df-8595d409c345@github.com>
Message-ID: <4Z0P0vu91bPMfm-Nf6CWRRQdPiSxjQo8DQUh14i8raI=.b173d9ed-5b73-49e5-b254-b48f78ac81e4@github.com>

On Tue, 17 Jun 2025 16:05:23 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1274:
> 
>> 1272:     vm_exit_during_initialization("Unable to use AOT cache.", nullptr);
>> 1273:   } else {
>> 1274:     vm_exit_during_initialization("Unable to use shared archive (unrecoverable archive loading error).", nullptr);
> 
> Who not to use message here instead of 'unrecoverable archive loading error'? The default message is 'unrecoverable error'. The default message can be updated to 'unrecoverable archive loading error'.

I added the message , that's a good idea !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2340532694

From jsikstro at openjdk.org  Thu Sep 11 12:47:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 12:47:33 GMT
Subject: RFR: 8367413: Use size_t instead of julong in runtime/arguments.cpp
Message-ID: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>

Hello,

There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t.

The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change.

Testing:
* Running through Oracle's tier1-3 on all Oracle supported platforms

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

Commit messages:
 - 8367413: Use size_t instead of julong in runtime/arguments.cpp

Changes: https://git.openjdk.org/jdk/pull/27224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367413
  Stats: 74 lines in 3 files changed: 0 ins; 3 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

PR: https://git.openjdk.org/jdk/pull/27224

From jsikstro at openjdk.org  Thu Sep 11 13:42:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 13:42:33 GMT
Subject: RFR: 8367413: Use size_t instead of julong in
 runtime/arguments.cpp [v2]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>

> Hello,
> 
> There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t.
> 
> The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change.
> 
> Testing:
> * Running through Oracle's tier1-3 on all Oracle supported platforms

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  size_t casts for 32-bit part of test_arguments.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/35c6057a..dba2ab46

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

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27224/head:pull/27224

PR: https://git.openjdk.org/jdk/pull/27224

From phubner at openjdk.org  Thu Sep 11 13:43:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 13:43:59 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test
Message-ID: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>

Hi all,

This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.

Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.

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

Commit messages:
 - Also remove the other condition.
 - Support large pages in InternSharedString CDS test.

Changes: https://git.openjdk.org/jdk/pull/27218/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367371
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27218.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27218/head:pull/27218

PR: https://git.openjdk.org/jdk/pull/27218

From ayang at openjdk.org  Thu Sep 11 13:49:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 11 Sep 2025 13:49:37 GMT
Subject: RFR: 8367413: Use size_t instead of julong in
 runtime/arguments.cpp [v2]
In-Reply-To: <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>
Message-ID: <D4OeaaQZ1gORSgSTq3lCWEK_0MzNfbMiPuTQD7Dv3pk=.e5d4626c-3e77-45c1-ac28-b23146dd3a17@github.com>

On Thu, 11 Sep 2025 13:42:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t.
>> 
>> The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change.
>> 
>> Testing:
>> * Running through Oracle's tier1-3 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   size_t casts for 32-bit part of test_arguments.cpp

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

> 1524:       FLAG_SET_ERGO(MaxRAM, (uint64_t)phys_mem);
> 1525:     } else {
> 1526:       phys_mem = (size_t)MaxRAM;

Pre-existing: I wonder if this should be `MIN2(MaxRAM, SIZE_MAX)` to handle 32-bit systems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2340949951

From phubner at openjdk.org  Thu Sep 11 14:00:33 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 14:00:33 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <teDoGKHZGSArDLnr9e94nOw46J4Pr4CXOtiXkDtLsSY=.2c455388-5a3c-4adf-8a13-63e5d40590f2@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
 <teDoGKHZGSArDLnr9e94nOw46J4Pr4CXOtiXkDtLsSY=.2c455388-5a3c-4adf-8a13-63e5d40590f2@github.com>
Message-ID: <lN-m6La6Ka2lX14HTjinxPNkw2h7M_827NQPMxRPiIw=.31c35d08-8df3-44f1-8cb3-ea2b15d4fe70@github.com>

On Thu, 11 Sep 2025 13:53:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>>   
>>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>
> test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java line 30:
> 
>> 28:  * @requires vm.cds.write.archived.java.heap
>> 29:  * @requires vm.gc == null
>> 30:  * @comment CDS archive heap mapping is not supported with large pages
> 
> We should remove the comment as well.
> Suggestion:

Good point, I missed that ? .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27218#discussion_r2341007120

From phubner at openjdk.org  Thu Sep 11 14:00:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 14:00:28 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
Message-ID: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>

> Hi all,
> 
> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
> 
> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
  
  Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27218/files
  - new: https://git.openjdk.org/jdk/pull/27218/files/3c928a9a..d33e1adc

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27218.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27218/head:pull/27218

PR: https://git.openjdk.org/jdk/pull/27218

From jsikstro at openjdk.org  Thu Sep 11 14:00:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 14:00:31 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
Message-ID: <teDoGKHZGSArDLnr9e94nOw46J4Pr4CXOtiXkDtLsSY=.2c455388-5a3c-4adf-8a13-63e5d40590f2@github.com>

On Thu, 11 Sep 2025 13:56:51 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
>> 
>> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Changes requested by jsikstro (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java line 30:

> 28:  * @requires vm.cds.write.archived.java.heap
> 29:  * @requires vm.gc == null
> 30:  * @comment CDS archive heap mapping is not supported with large pages

We should remove the comment as well.
Suggestion:

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

PR Review: https://git.openjdk.org/jdk/pull/27218#pullrequestreview-3211750482
PR Review Comment: https://git.openjdk.org/jdk/pull/27218#discussion_r2340988758

From ayang at openjdk.org  Thu Sep 11 14:04:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 11 Sep 2025 14:04:35 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
Message-ID: <UmNZgE4QTZ4VqwnQa_sbaO13Psa_2npd9oA2iO6HxtI=.cf550428-507d-43fa-8d46-be50ea739cb0@github.com>

On Thu, 11 Sep 2025 14:00:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
>> 
>> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27218#pullrequestreview-3211799425

From jsikstro at openjdk.org  Thu Sep 11 14:04:37 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Sep 2025 14:04:37 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
Message-ID: <T38Yv7Q0RVhpMGoDep3McwSSDRyAy-ua0hqdTjj-GUs=.af912555-f30a-406e-92cf-7afbf1a933d4@github.com>

On Thu, 11 Sep 2025 14:00:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
>> 
>> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Looks good. Thank you!

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27218#pullrequestreview-3211805488

From mdoerr at openjdk.org  Thu Sep 11 15:47:34 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 11 Sep 2025 15:47:34 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v5]
In-Reply-To: <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>
Message-ID: <GoqyKmSd6nBruw32e1RdvEz53StKYhCmT_xP6FoAEI4=.5eadae3f-be05-43b4-aea3-3eee429c8136@github.com>

On Thu, 11 Sep 2025 12:00:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

Otherwise, LGTM.

src/hotspot/share/cds/aotMetaspace.cpp line 1291:

> 1289:     vm_exit_during_initialization("Unable to use AOT cache.", nullptr);
> 1290:   } else {
> 1291:     vm_exit_during_initialization("Unable to use shared archive. Unrecoverable archive loading error", message);

Maybe we should add a hint like "Run with -Xlog:aot,cds for details."?

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

PR Comment: https://git.openjdk.org/jdk/pull/25846#issuecomment-3281519585
PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2341512385

From iklam at openjdk.org  Thu Sep 11 22:41:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Sep 2025 22:41:08 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
Message-ID: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>

The assert happens because we attempt to allocate Java objects while holding a mutex:


    MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
    list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
    for (int i = 0; i < len; i++) {
      Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);


It's possible for the allocations to trigger a call to Java when JVMTI is enabled.

The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.

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

Commit messages:
 - @liach comment -- assert only dumper thread can call LambdaFormInvokers::regenerate_holder_classes()
 - 8360269: Incorrect lock usage in LambdaFormInvokers::regenerate_holder_classes

Changes: https://git.openjdk.org/jdk/pull/27231/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367475
  Stats: 40 lines in 3 files changed: 24 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27231/head:pull/27231

PR: https://git.openjdk.org/jdk/pull/27231

From iklam at openjdk.org  Thu Sep 11 22:41:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Sep 2025 22:41:10 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <PuICXm2HZXTp_luuoBgCSd8Dv409CTIFtthX1QL-4vE=.29451d62-df08-4ba6-b7c9-46c1268698b6@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <PuICXm2HZXTp_luuoBgCSd8Dv409CTIFtthX1QL-4vE=.29451d62-df08-4ba6-b7c9-46c1268698b6@github.com>
Message-ID: <ORkfu-H2ysRYWpWshcKf5sXbt5J90mZojgVXhq9NXk8=.754d938b-b82d-46c1-ae27-3dff0808e108@github.com>

On Thu, 11 Sep 2025 20:58:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The assert happens because we attempt to allocate Java objects while holding a mutex:
>> 
>> 
>>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>>     for (int i = 0; i < len; i++) {
>>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
>> 
>> 
>> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
>> 
>> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.
>
> src/hotspot/share/cds/lambdaFormInvokers.cpp line 133:
> 
>> 131:     // Stop other threads from recording into _lambdaform_lines.
>> 132:     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>> 133:     _stop_appending = true;
> 
> Should we assert only one thread can set this _stop_appending? If multiple threads go through this, I recommend adding a distinct logging message from the "Nothing to regenerate" below.

I added an assert that this function can be called only from the "dumper thread", which is the Java thread that drives the AOT cache creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342415440

From liach at openjdk.org  Thu Sep 11 22:41:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Sep 2025 22:41:09 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
Message-ID: <PuICXm2HZXTp_luuoBgCSd8Dv409CTIFtthX1QL-4vE=.29451d62-df08-4ba6-b7c9-46c1268698b6@github.com>

On Thu, 11 Sep 2025 17:22:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The assert happens because we attempt to allocate Java objects while holding a mutex:
> 
> 
>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>     for (int i = 0; i < len; i++) {
>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
> 
> 
> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
> 
> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.

Seems reasonable.

src/hotspot/share/cds/lambdaFormInvokers.cpp line 133:

> 131:     // Stop other threads from recording into _lambdaform_lines.
> 132:     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
> 133:     _stop_appending = true;

Should we assert only one thread can set this _stop_appending? If multiple threads go through this, I recommend adding a distinct logging message from the "Nothing to regenerate" below.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27231#pullrequestreview-3213815081
PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342327339

From iklam at openjdk.org  Fri Sep 12 02:24:12 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Sep 2025 02:24:12 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
Message-ID: <v9DtrAl3FNhJSpVPdyjdrLBgFW-1VN581zZhrjM8QP8=.92971406-3518-4695-ad53-3de19e2e8b59@github.com>

On Thu, 11 Sep 2025 14:00:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
>> 
>> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Thanks for fixing it!

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27218#pullrequestreview-3214379549

From dholmes at openjdk.org  Fri Sep 12 02:24:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 02:24:12 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <C_MBZcdPBYQCnBFf5jLoa8DnTlWAfUfemx8VoCQkuFA=.5a186512-9876-43a9-8533-264cc9a047cc@github.com>

On Tue, 2 Sep 2025 07:07:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 347:

> 345: 
> 346: class VirtualMemoryWalker : public StackObj {
> 347: public:

Suggestion:

 public:

The access modifier should be indented by 1

test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 50:

> 48:       MemTracker::NmtVirtualMemoryLocker nvml;
> 49:       VirtualMemoryTracker::Instance::snapshot_thread_stacks();
> 50:     }

Why two separate locking blocks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2342779331
PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2342780510

From dholmes at openjdk.org  Fri Sep 12 02:47:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 02:47:14 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
Message-ID: <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>

On Thu, 11 Sep 2025 17:22:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The assert happens because we attempt to allocate Java objects while holding a mutex:
> 
> 
>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>     for (int i = 0; i < len; i++) {
>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
> 
> 
> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
> 
> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.

Seems reasonable. Thanks

Note that if you ever call a function with CHECK inside a mutex-locker scope you are potentially going to break the locking rule.

src/hotspot/share/cds/cdsConfig.cpp line 870:

> 868: bool CDSConfig::current_thread_is_dumper() {
> 869:   Thread* t = Thread::current();
> 870:   return t != nullptr && t == _dumper_thread;

Do you really need the null check here? How could an unattached thread be executing this?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27231#pullrequestreview-3214398458
PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342796930

From iklam at openjdk.org  Fri Sep 12 03:25:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Sep 2025 03:25:13 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>
Message-ID: <gWw9J9cTl1B07hagdGt7YS0yRNcrIc1HBe-u2TUukZo=.e2f8fa18-a6e3-4eca-8d59-49c3ec086081@github.com>

On Fri, 12 Sep 2025 02:37:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The assert happens because we attempt to allocate Java objects while holding a mutex:
>> 
>> 
>>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>>     for (int i = 0; i < len; i++) {
>>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
>> 
>> 
>> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
>> 
>> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.
>
> src/hotspot/share/cds/cdsConfig.cpp line 870:
> 
>> 868: bool CDSConfig::current_thread_is_dumper() {
>> 869:   Thread* t = Thread::current();
>> 870:   return t != nullptr && t == _dumper_thread;
> 
> Do you really need the null check here? How could an unattached thread be executing this?

I am not sure, but it surely doesn't hurt. I want to make sure that if this is called when `_dumper_thread` is not initialized, we will return `false` for any thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342846105

From dholmes at openjdk.org  Fri Sep 12 03:54:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 03:54:19 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <gWw9J9cTl1B07hagdGt7YS0yRNcrIc1HBe-u2TUukZo=.e2f8fa18-a6e3-4eca-8d59-49c3ec086081@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>
 <gWw9J9cTl1B07hagdGt7YS0yRNcrIc1HBe-u2TUukZo=.e2f8fa18-a6e3-4eca-8d59-49c3ec086081@github.com>
Message-ID: <JSO_l2jbTkqc2PzAGYApFg5xJDzUwcpQ9PYFXommiLQ=.68ba5bd0-b5dc-4615-8352-4f4067ddb418@github.com>

On Fri, 12 Sep 2025 03:22:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConfig.cpp line 870:
>> 
>>> 868: bool CDSConfig::current_thread_is_dumper() {
>>> 869:   Thread* t = Thread::current();
>>> 870:   return t != nullptr && t == _dumper_thread;
>> 
>> Do you really need the null check here? How could an unattached thread be executing this?
>
> I am not sure, but it surely doesn't hurt. I want to make sure that if this is called when `_dumper_thread` is not initialized, we will return `false` for any thread.

It gives the impression that null is possible somehow. But it will assert if that happens - which I doubt is possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342874535

From iklam at openjdk.org  Fri Sep 12 04:20:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Sep 2025 04:20:27 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
Message-ID: <zv2Z5IM_QdCHLMJzhMuGz0-Qjf_JqlirD2Opk2LxKHk=.217cc922-2f70-4983-9270-f74a5c6c505f@github.com>

> The assert happens because we attempt to allocate Java objects while holding a mutex:
> 
> 
>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>     for (int i = 0; i < len; i++) {
>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
> 
> 
> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
> 
> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comment - Thread::current() never returns nullptr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27231/files
  - new: https://git.openjdk.org/jdk/pull/27231/files/f018244e..b6f054da

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

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27231/head:pull/27231

PR: https://git.openjdk.org/jdk/pull/27231

From iklam at openjdk.org  Fri Sep 12 04:20:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Sep 2025 04:20:28 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <JSO_l2jbTkqc2PzAGYApFg5xJDzUwcpQ9PYFXommiLQ=.68ba5bd0-b5dc-4615-8352-4f4067ddb418@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>
 <gWw9J9cTl1B07hagdGt7YS0yRNcrIc1HBe-u2TUukZo=.e2f8fa18-a6e3-4eca-8d59-49c3ec086081@github.com>
 <JSO_l2jbTkqc2PzAGYApFg5xJDzUwcpQ9PYFXommiLQ=.68ba5bd0-b5dc-4615-8352-4f4067ddb418@github.com>
Message-ID: <kvNZbfs-H0G8WEhB6rqUczaC6KIwus8Vqio_0Vnhshg=.17f49bbd-6cbe-48f5-98f3-939aa05f24f2@github.com>

On Fri, 12 Sep 2025 03:51:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I am not sure, but it surely doesn't hurt. I want to make sure that if this is called when `_dumper_thread` is not initialized, we will return `false` for any thread.
>
> It gives the impression that null is possible somehow. But it will assert if that happens - which I doubt is possible.

Oh I didn't realize that `Thread::current()` never returns null. I've updated `current_thread_is_vm_or_dumper()` and `current_thread_is_dumper()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342906953

From dholmes at openjdk.org  Fri Sep 12 05:58:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 05:58:09 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <kvNZbfs-H0G8WEhB6rqUczaC6KIwus8Vqio_0Vnhshg=.17f49bbd-6cbe-48f5-98f3-939aa05f24f2@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <qwiFTacP_8RMPtjy0NhoxZNXWMHI_cFIMd7PB2C9B-8=.b39f0ce0-a053-45c5-b55d-d43ec7570e17@github.com>
 <gWw9J9cTl1B07hagdGt7YS0yRNcrIc1HBe-u2TUukZo=.e2f8fa18-a6e3-4eca-8d59-49c3ec086081@github.com>
 <JSO_l2jbTkqc2PzAGYApFg5xJDzUwcpQ9PYFXommiLQ=.68ba5bd0-b5dc-4615-8352-4f4067ddb418@github.com>
 <kvNZbfs-H0G8WEhB6rqUczaC6KIwus8Vqio_0Vnhshg=.17f49bbd-6cbe-48f5-98f3-939aa05f24f2@github.com>
Message-ID: <15fomOwMGTWanGXx6cSJCHEFM7ZwzXiSCoquxuf_i0c=.f1b6f609-2068-47cd-b9b1-a80108d5f5df@github.com>

On Fri, 12 Sep 2025 04:16:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It gives the impression that null is possible somehow. But it will assert if that happens - which I doubt is possible.
>
> Oh I didn't realize that `Thread::current()` never returns null. I've updated `current_thread_is_vm_or_dumper()` and `current_thread_is_dumper()`.

I assumed the code wanted to assert on null but handled it in release mode, just in case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2343058040

From dholmes at openjdk.org  Fri Sep 12 06:01:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 06:01:14 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <zv2Z5IM_QdCHLMJzhMuGz0-Qjf_JqlirD2Opk2LxKHk=.217cc922-2f70-4983-9270-f74a5c6c505f@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <zv2Z5IM_QdCHLMJzhMuGz0-Qjf_JqlirD2Opk2LxKHk=.217cc922-2f70-4983-9270-f74a5c6c505f@github.com>
Message-ID: <cHIEJxBjynicM9GgYqkh0Go3H-GKUzSzYJgT2Hgq1xY=.a91da245-6c1a-49aa-9034-8384b755030a@github.com>

On Fri, 12 Sep 2025 04:20:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The assert happens because we attempt to allocate Java objects while holding a mutex:
>> 
>> 
>>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>>     for (int i = 0; i < len; i++) {
>>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
>> 
>> 
>> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
>> 
>> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comment - Thread::current() never returns nullptr

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27231#pullrequestreview-3214778161

From jsikstro at openjdk.org  Fri Sep 12 07:11:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Sep 2025 07:11:24 GMT
Subject: RFR: 8367413: Use size_t instead of julong in
 runtime/arguments.cpp [v2]
In-Reply-To: <D4OeaaQZ1gORSgSTq3lCWEK_0MzNfbMiPuTQD7Dv3pk=.e5d4626c-3e77-45c1-ac28-b23146dd3a17@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>
 <D4OeaaQZ1gORSgSTq3lCWEK_0MzNfbMiPuTQD7Dv3pk=.e5d4626c-3e77-45c1-ac28-b23146dd3a17@github.com>
Message-ID: <EvhvgqKqem25ZWRzxURW2ASf7YKk8qQMwda65e8-BZc=.2a394dfa-1193-4bef-9a04-6a8d4cfa0534@github.com>

On Thu, 11 Sep 2025 13:46:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   size_t casts for 32-bit part of test_arguments.cpp
>
> src/hotspot/share/runtime/arguments.cpp line 1526:
> 
>> 1524:       FLAG_SET_ERGO(MaxRAM, (uint64_t)phys_mem);
>> 1525:     } else {
>> 1526:       phys_mem = (size_t)MaxRAM;
> 
> Pre-existing: I wonder if this should be `MIN2(MaxRAM, SIZE_MAX)` to handle 32-bit systems.

>From the discussion surrounding [JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485), we support this since we could run a 32-bit VM on a 64-bit machine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2343223296

From jsikstro at openjdk.org  Fri Sep 12 07:20:28 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Sep 2025 07:20:28 GMT
Subject: RFR: 8367413: Use size_t instead of julong in
 runtime/arguments.cpp [v2]
In-Reply-To: <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <vkgWl2AhvN1P_3SV1i242WR2O9bOxOlUTRC3FpQ-_Vk=.803b8b2b-da38-4245-ba85-92ce028f916d@github.com>
Message-ID: <RTsr8Kyf3GkcHvZhKX8C0LAM6shaKgszBYzxKyQp2VM=.db38a244-ba7b-42aa-9b1b-7d4f93ac74ee@github.com>

On Thu, 11 Sep 2025 13:42:33 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> There are several unnecessary uses of the julong type in arguments.cpp that could use size_t instead to fit in better with surrounding code. Almost all flags that are read in arguments.cpp are size_t, and the os functions it interacts with were changed from julong to size_t in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086) or are already taking in size_t.
>> 
>> The main usage of julong in runtime/arguments.cpp is in Arguments::set_heap_size() and Arguments::set_aggressive_heap_flags(), where there are a lot of casts from julong types to size_t which could be removed with this change.
>> 
>> Testing:
>> * Running through Oracle's tier1-3 on all Oracle supported platforms
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   size_t casts for 32-bit part of test_arguments.cpp

When looking at this we found some irregularities with the code that is being changed in this PR when running in a 32-bit VM.

I think we should hold off on this until there is a solution in place for [JDK-8367485](https://bugs.openjdk.org/browse/JDK-8367485), so I'll move this to a draft in the meantime.

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

PR Comment: https://git.openjdk.org/jdk/pull/27224#issuecomment-3284069670

From stefank at openjdk.org  Fri Sep 12 07:35:19 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 07:35:19 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess files
Message-ID: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>

JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.

Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.

I will verify that this still builds on the platform that I can easily build.

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

Commit messages:
 - 8367014: Change prefix for platform-dependent AtomicAccess files

Changes: https://git.openjdk.org/jdk/pull/27245/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27245&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367486
  Stats: 52 lines in 14 files changed: 0 ins; 1 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/27245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27245/head:pull/27245

PR: https://git.openjdk.org/jdk/pull/27245

From azafari at openjdk.org  Fri Sep 12 07:38:46 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 12 Sep 2025 07:38:46 GMT
Subject: RFR: 8366884: NMT fails with MallocLimit: reached category
 "mtCompiler" limit
Message-ID: <bs7bvViPRH0l5vATEy7vssHhJ1Rm6GEhbBm3Fs53CH0=.c6f7cc50-0883-4115-a770-6c9b1c305788@github.com>

The JTREG test expects that jvm exits with error on malloc-limit reached. JVM reports this and exits but test is timed out before reading the output.
The timeout value for the test is set explicitly to 480. 

Tested couple of 100 times in mach5.

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

Commit messages:
 - 8366884: NMT fails with MallocLimit: reached category "mtCompiler" limit

Changes: https://git.openjdk.org/jdk/pull/27246/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27246&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366884
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27246/head:pull/27246

PR: https://git.openjdk.org/jdk/pull/27246

From stefank at openjdk.org  Fri Sep 12 07:41:28 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 07:41:28 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v2]
In-Reply-To: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
Message-ID: <73oYDi9ZElcT33O3eNkTR2Dr_C6Yeswd9i--X_pXy4o=.12dc1bd7-7599-49f1-b8a7-6b5191e63d3a@github.com>

> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
> 
> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
> 
> I will verify that this still builds on the platform that I can easily build.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Complete revert of atomicAccess_aarch64.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27245/files
  - new: https://git.openjdk.org/jdk/pull/27245/files/81663b47..7c8898de

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27245/head:pull/27245

PR: https://git.openjdk.org/jdk/pull/27245

From mbaesken at openjdk.org  Fri Sep 12 07:43:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Sep 2025 07:43:58 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v6]
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Add hint suggested by mdoerr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25846/files
  - new: https://git.openjdk.org/jdk/pull/25846/files/5784207f..0f098f27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846

PR: https://git.openjdk.org/jdk/pull/25846

From mbaesken at openjdk.org  Fri Sep 12 07:44:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Sep 2025 07:44:01 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v5]
In-Reply-To: <GoqyKmSd6nBruw32e1RdvEz53StKYhCmT_xP6FoAEI4=.5eadae3f-be05-43b4-aea3-3eee429c8136@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <zP5nkXgV7hefRfjnw2ASs5AcogisX1YRB-0KHvI-UBU=.cb5bcd00-e2a7-4b08-9dad-9451b66f4255@github.com>
 <GoqyKmSd6nBruw32e1RdvEz53StKYhCmT_xP6FoAEI4=.5eadae3f-be05-43b4-aea3-3eee429c8136@github.com>
Message-ID: <N9AE4LooFpvpcZN9Y2u-Q2fmjRi4gyBjjCzDp0OALuU=.93be5a44-a5c4-4a94-951f-90f4f2533061@github.com>

On Thu, 11 Sep 2025 15:43:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/cds/aotMetaspace.cpp line 1291:
> 
>> 1289:     vm_exit_during_initialization("Unable to use AOT cache.", nullptr);
>> 1290:   } else {
>> 1291:     vm_exit_during_initialization("Unable to use shared archive. Unrecoverable archive loading error", message);
> 
> Maybe we should add a hint like "Run with -Xlog:aot,cds for details."?

Sounds like a good idea, I added the hint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2343294180

From azafari at openjdk.org  Fri Sep 12 08:03:39 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 12 Sep 2025 08:03:39 GMT
Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with ASAN
Message-ID: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>

When ASAN is enabled, memories allocated from ChunkManager are poisoned/unpoisoned. These un-/poisoning are done in ctor/dtor of VirtualSpaceNode and whenever chunks come/leave the ChunkManager list. Since chunks can be merged or split the poisoning should also follow the new memory segments correspondingly. To have a more precise control over where/when do the un-/poisoning, the ASAN poisoning/unpoisoning memory regions is moved after os::uncommit/commit operations.

Tested on tiers1-5

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

Commit messages:
 - 8365385: [asan] os::pretouch_memory() is not compatible with ASAN

Changes: https://git.openjdk.org/jdk/pull/27248/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365385
  Stats: 22 lines in 2 files changed: 4 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27248/head:pull/27248

PR: https://git.openjdk.org/jdk/pull/27248

From stefank at openjdk.org  Fri Sep 12 08:08:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 08:08:48 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
Message-ID: <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>

> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
> 
> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
> 
> I will verify that this still builds on the platform that I can easily build.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Fix zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27245/files
  - new: https://git.openjdk.org/jdk/pull/27245/files/7c8898de..30e51731

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27245&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27245&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27245/head:pull/27245

PR: https://git.openjdk.org/jdk/pull/27245

From mdoerr at openjdk.org  Fri Sep 12 08:11:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 12 Sep 2025 08:11:43 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v6]
In-Reply-To: <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
Message-ID: <oSB8-S0Ft7-7Y2oAbuBsDDc2Qob0ydL4nHIZNZ6OCoc=.9719bb8f-88d9-44a5-9c42-a689b4ac1ba5@github.com>

On Fri, 12 Sep 2025 07:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hint suggested by mdoerr

Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25846#pullrequestreview-3215305916

From phubner at openjdk.org  Fri Sep 12 08:14:27 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 08:14:27 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <j-nnQ4qJd4mHCvmBlI_IGJd-UlkQgtWp8EfVy49ocYo=.30b2d415-aa95-484d-acdc-8cf67e5f9b6a@github.com>

On Tue, 2 Sep 2025 07:07:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

src/hotspot/share/nmt/memTracker.hpp line 176:

> 174:   }
> 175: 
> 176:   static inline bool walk_virtual_memory(VirtualMemoryWalker* walker) {

Nit: should probably be in `memTracker.inline.hpp`?

src/hotspot/share/nmt/memTracker.hpp line 183:

> 181:   }
> 182: 
> 183:   static inline MemoryFileTracker::MemoryFile* register_file(const char* descriptive_name) {

Same here. I wonder why we have the inline header when it only contains `MemTracker::check_exceeds_limit`...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343359401
PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343361247

From phubner at openjdk.org  Fri Sep 12 08:14:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 08:14:29 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
In-Reply-To: <AHTxm1SV6IWbcwnfj7po-R8WvhrM0ui4K0Rf22P3HAE=.f457b1a7-5b33-47f3-98ca-739b906cb80d@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <AHTxm1SV6IWbcwnfj7po-R8WvhrM0ui4K0Rf22P3HAE=.f457b1a7-5b33-47f3-98ca-739b906cb80d@github.com>
Message-ID: <5Lq6_nN9dhbbd3M5otNjAIfHFSqrc4Od10yQItnXu0I=.f2e3ea29-2d18-41ae-9ad5-0804d93c80a3@github.com>

On Thu, 4 Sep 2025 07:42:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
>> 
>> Passes tier1.
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 221:
> 
>> 219:   });
>> 220:   return ret;
>> 221: }
> 
> A VirtualMemoryWalker returned true or false depending on whether or not its operation succeeded, and we are meant to pass that along as the return value of walk_virtual_memory. That was missing, now fixed.

Nice catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343365995

From asteiner at openjdk.org  Fri Sep 12 08:27:29 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 12 Sep 2025 08:27:29 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v6]
In-Reply-To: <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
Message-ID: <Ze-nj2wgsSD_BbWBfGDSarK2Q8gocqHMThgB0-BtFHo=.612e9e8f-7b59-4ede-b4dc-d9b1314a6b23@github.com>

On Fri, 12 Sep 2025 07:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hint suggested by mdoerr

LGTM

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

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/25846#pullrequestreview-3215358247

From azafari at openjdk.org  Fri Sep 12 08:33:56 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 12 Sep 2025 08:33:56 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v4]
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <ES-BBbjqHk6OBpc__DHUJCtlI0b9dNRoDz_cO6UAPTM=.73baf150-3dea-4eda-898a-1d9e1cd789b8@github.com>

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  comment fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26983/files
  - new: https://git.openjdk.org/jdk/pull/26983/files/2e868e33..5eb796b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983

PR: https://git.openjdk.org/jdk/pull/26983

From jsjolen at openjdk.org  Fri Sep 12 09:11:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Sep 2025 09:11:19 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v2]
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <jj7z8uhoXGKZa6uA6hh0xbBLP5TgawuumQBpFyinYdY=.a587fbe8-0327-44bd-9b41-41eb200c53b5@github.com>

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/nmt/virtualMemoryTracker.hpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27038/files
  - new: https://git.openjdk.org/jdk/pull/27038/files/20d2f5de..1cb83538

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27038/head:pull/27038

PR: https://git.openjdk.org/jdk/pull/27038

From phubner at openjdk.org  Fri Sep 12 09:11:19 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 09:11:19 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v2]
In-Reply-To: <jj7z8uhoXGKZa6uA6hh0xbBLP5TgawuumQBpFyinYdY=.a587fbe8-0327-44bd-9b41-41eb200c53b5@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <jj7z8uhoXGKZa6uA6hh0xbBLP5TgawuumQBpFyinYdY=.a587fbe8-0327-44bd-9b41-41eb200c53b5@github.com>
Message-ID: <ctZ9bfASql3MnAolHqr6nwJp5ICVi_PtmEYhWRa5OMM=.742aa610-35d7-4a1e-b3a4-5c1204adab1b@github.com>

On Fri, 12 Sep 2025 09:08:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
>> 
>> Passes tier1.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/nmt/virtualMemoryTracker.hpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Happy to address the inline header refactoring separately.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/27038#pullrequestreview-3215569932

From jsjolen at openjdk.org  Fri Sep 12 09:11:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Sep 2025 09:11:21 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v2]
In-Reply-To: <j-nnQ4qJd4mHCvmBlI_IGJd-UlkQgtWp8EfVy49ocYo=.30b2d415-aa95-484d-acdc-8cf67e5f9b6a@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <j-nnQ4qJd4mHCvmBlI_IGJd-UlkQgtWp8EfVy49ocYo=.30b2d415-aa95-484d-acdc-8cf67e5f9b6a@github.com>
Message-ID: <yLimlcHU6CtLl33FkXsmsxMlP2nVAjgVfR5_-2xgCUw=.60528833-5ad8-4d24-9693-18b2ed5f2693@github.com>

On Fri, 12 Sep 2025 08:06:52 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/nmt/virtualMemoryTracker.hpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/nmt/memTracker.hpp line 183:
> 
>> 181:   }
>> 182: 
>> 183:   static inline MemoryFileTracker::MemoryFile* register_file(const char* descriptive_name) {
> 
> Same here. I wonder why we have the inline header when it only contains `MemTracker::check_exceeds_limit`...

Hmm, so do I. I've never used the inline header myself. I think moving stuff over to the inline header is something we should think about in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343536623

From phubner at openjdk.org  Fri Sep 12 09:11:22 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 09:11:22 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v2]
In-Reply-To: <yLimlcHU6CtLl33FkXsmsxMlP2nVAjgVfR5_-2xgCUw=.60528833-5ad8-4d24-9693-18b2ed5f2693@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <j-nnQ4qJd4mHCvmBlI_IGJd-UlkQgtWp8EfVy49ocYo=.30b2d415-aa95-484d-acdc-8cf67e5f9b6a@github.com>
 <yLimlcHU6CtLl33FkXsmsxMlP2nVAjgVfR5_-2xgCUw=.60528833-5ad8-4d24-9693-18b2ed5f2693@github.com>
Message-ID: <u6usxrE4toppshFbWT-y84UDW1Wougu34qqHnaQfmlU=.05b79430-cb59-4885-9835-67a9128e942c@github.com>

On Fri, 12 Sep 2025 09:05:50 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/nmt/memTracker.hpp line 183:
>> 
>>> 181:   }
>>> 182: 
>>> 183:   static inline MemoryFileTracker::MemoryFile* register_file(const char* descriptive_name) {
>> 
>> Same here. I wonder why we have the inline header when it only contains `MemTracker::check_exceeds_limit`...
>
> Hmm, so do I. I've never used the inline header myself. I think moving stuff over to the inline header is something we should think about in a separate PR.

I'm okay with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343539573

From jsjolen at openjdk.org  Fri Sep 12 09:11:24 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Sep 2025 09:11:24 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v2]
In-Reply-To: <C_MBZcdPBYQCnBFf5jLoa8DnTlWAfUfemx8VoCQkuFA=.5a186512-9876-43a9-8533-264cc9a047cc@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <C_MBZcdPBYQCnBFf5jLoa8DnTlWAfUfemx8VoCQkuFA=.5a186512-9876-43a9-8533-264cc9a047cc@github.com>
Message-ID: <C1D1I_z0xZ3-rZyN60fSkhF6yUMW-mLDBQR7u6xty8k=.99f8ee76-f31b-4036-afa6-d6f4ba1846ab@github.com>

On Fri, 12 Sep 2025 02:19:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/nmt/virtualMemoryTracker.hpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 347:
> 
>> 345: 
>> 346: class VirtualMemoryWalker : public StackObj {
>> 347: public:
> 
> Suggestion:
> 
>  public:
> 
> The access modifier should be indented by 1

You're right, that is the style of this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343542580

From jsjolen at openjdk.org  Fri Sep 12 09:16:47 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Sep 2025 09:16:47 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v3]
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <1OaakMl3Kt0xF7zuTwTkmYv2V_4cMmv32bwjSssGZyM=.3768a258-b297-4c5e-a13c-55b512c7bc7a@github.com>

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/missing-locks' into missing-locks
 - Merge lock blocks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27038/files
  - new: https://git.openjdk.org/jdk/pull/27038/files/1cb83538..2b4f53e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27038&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27038&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27038/head:pull/27038

PR: https://git.openjdk.org/jdk/pull/27038

From jsjolen at openjdk.org  Fri Sep 12 09:16:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 12 Sep 2025 09:16:49 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v3]
In-Reply-To: <C_MBZcdPBYQCnBFf5jLoa8DnTlWAfUfemx8VoCQkuFA=.5a186512-9876-43a9-8533-264cc9a047cc@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <C_MBZcdPBYQCnBFf5jLoa8DnTlWAfUfemx8VoCQkuFA=.5a186512-9876-43a9-8533-264cc9a047cc@github.com>
Message-ID: <LWa0n7c7D5XkHrQZJ-96qgQ1elcPw_CMqKyM9xCJsrk=.8184d5b1-e7da-4bd5-9f97-3703bb7af932@github.com>

On Fri, 12 Sep 2025 02:20:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/missing-locks' into missing-locks
>>  - Merge lock blocks
>
> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 50:
> 
>> 48:       MemTracker::NmtVirtualMemoryLocker nvml;
>> 49:       VirtualMemoryTracker::Instance::snapshot_thread_stacks();
>> 50:     }
> 
> Why two separate locking blocks?

No reason, let's merge them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27038#discussion_r2343550127

From ayang at openjdk.org  Fri Sep 12 11:11:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Sep 2025 11:11:10 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
Message-ID: <v6uDUVPB6ZaRP2yotRkGeXpr45fXZUh1WptAY3Sraxw=.6d9af595-549d-4ec5-bb56-233db146846e@github.com>

On Fri, 12 Sep 2025 08:08:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
>> 
>> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
>> 
>> I will verify that this still builds on the platform that I can easily build.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix zero

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27245#pullrequestreview-3216140984

From phubner at openjdk.org  Fri Sep 12 11:36:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 11:36:32 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
Message-ID: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>

Hi all,

`FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
1) refactors `constantPoolOop` to be a hidden VM injected field `vmtarget` (name to be consistent with other similar cases),
2) removes `FilteredJavaFieldStream` entirely, and
3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.

Testing: Oracle tiers 1-3.

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

Commit messages:
 - Fix typo.
 - Refactor to purely use injected fields.
 - Remove FilteredJavaFieldStream and usages.
 - Remove constantPoolOop from Java code.
 - Make constantPoolOop a hidden vmholder field.

Changes: https://git.openjdk.org/jdk/pull/27209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365858
  Stats: 194 lines in 9 files changed: 8 ins; 166 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209

PR: https://git.openjdk.org/jdk/pull/27209

From azafari at openjdk.org  Fri Sep 12 12:32:16 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 12 Sep 2025 12:32:16 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v3]
In-Reply-To: <1OaakMl3Kt0xF7zuTwTkmYv2V_4cMmv32bwjSssGZyM=.3768a258-b297-4c5e-a13c-55b512c7bc7a@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <1OaakMl3Kt0xF7zuTwTkmYv2V_4cMmv32bwjSssGZyM=.3768a258-b297-4c5e-a13c-55b512c7bc7a@github.com>
Message-ID: <gpvp_C8eTjcAKt-JzhkbCDYGbVdAIS7Ke0mRIBgp-0E=.6ae6a563-fe72-46ef-8ffb-023b3d41ca40@github.com>

On Fri, 12 Sep 2025 09:16:47 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
>> 
>> Passes tier1.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/missing-locks' into missing-locks
>  - Merge lock blocks

LGTM. Thanks.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27038#pullrequestreview-3216452728

From eastigeevich at openjdk.org  Fri Sep 12 13:05:24 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 12 Sep 2025 13:05:24 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v6]
In-Reply-To: <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
Message-ID: <QfkPXIIkn1A35St4Ar8jD-quLaYKVMGhNj0QGZyw22U=.be953b00-81ae-4b0d-a886-857c6babe1bb@github.com>

On Fri, 12 Sep 2025 07:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hint suggested by mdoerr

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25846#pullrequestreview-3216593770

From phubner at openjdk.org  Fri Sep 12 14:14:43 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 14:14:43 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <T38Yv7Q0RVhpMGoDep3McwSSDRyAy-ua0hqdTjj-GUs=.af912555-f30a-406e-92cf-7afbf1a933d4@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
 <T38Yv7Q0RVhpMGoDep3McwSSDRyAy-ua0hqdTjj-GUs=.af912555-f30a-406e-92cf-7afbf1a933d4@github.com>
Message-ID: <HhQzMEvdrrv1lZROfpQwxZwvyFWrHgWW7oKKP4GqZT8=.1fe4f015-817f-41b0-9cdd-fbda0802614c@github.com>

On Thu, 11 Sep 2025 14:01:23 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>>   
>>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>
> Looks good. Thank you!

Thanks for the reviews, @jsikstro, @albertnetymk, @iklam.

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

PR Comment: https://git.openjdk.org/jdk/pull/27218#issuecomment-3285452973

From duke at openjdk.org  Fri Sep 12 14:17:48 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Sep 2025 14:17:48 GMT
Subject: RFR: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test [v2]
In-Reply-To: <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
 <Lf-qjSceyy98aOkZXlm8T5m7Ay06WmEKyXmTUeh5NSQ=.d01390f4-5899-4e89-94a5-5802ab869c69@github.com>
Message-ID: <KiuqPQvmsjIFyhVPd5UMefXXVNIdP_VQ41Y5zF5jsaQ=.c626ce17-0a27-4277-b43e-26820df67aba@github.com>

On Thu, 11 Sep 2025 14:00:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
>> 
>> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

@Arraying 
Your change (at version d33e1adc6fc4b5d8aefb2e0a7a3ab560b1d64b54) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27218#issuecomment-3285463110

From phubner at openjdk.org  Fri Sep 12 14:27:38 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 14:27:38 GMT
Subject: Integrated: 8367371: Remove @requires vm.opt.UseLargePages from
 InternSharedString.java test
In-Reply-To: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
References: <e_KUbyVqnipKxN0SvLXMM9Qfuq7A0UYssMYP28XbtWo=.57cd6798-f0ff-4bb7-9f13-c064ac46aaee@github.com>
Message-ID: <UhcDAvIiJoBVpBqYWW1k6mlAx6qUC8TxmcVAgbvnQ8Q=.af0a7368-6e07-4b4b-adc1-03c9ddef91a2@github.com>

On Thu, 11 Sep 2025 11:11:30 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR removes the requirement to not use large pages for the given CDS test. CDS now supports large pages.
> 
> Tested `InternSharedString.java` on Linux x64 and Linux AArch64 with `-XX:+UseLargePages`. 5x 100 iterations.

This pull request has now been integrated.

Changeset: 10fea860
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10fea860029c4702208fe6b175b6ab8062c75f60
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8367371: Remove @requires vm.opt.UseLargePages from InternSharedString.java test

Reviewed-by: jsikstro, ayang, iklam

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

PR: https://git.openjdk.org/jdk/pull/27218

From matsaave at openjdk.org  Fri Sep 12 14:37:53 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 12 Sep 2025 14:37:53 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <zv2Z5IM_QdCHLMJzhMuGz0-Qjf_JqlirD2Opk2LxKHk=.217cc922-2f70-4983-9270-f74a5c6c505f@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <zv2Z5IM_QdCHLMJzhMuGz0-Qjf_JqlirD2Opk2LxKHk=.217cc922-2f70-4983-9270-f74a5c6c505f@github.com>
Message-ID: <hYXTEJnJbeY6Ih837ZefGxW948bgwszyl-45jtb3Qz0=.15b90a6f-bf50-4ec5-a7b6-0bb45cc9bfbc@github.com>

On Fri, 12 Sep 2025 04:20:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The assert happens because we attempt to allocate Java objects while holding a mutex:
>> 
>> 
>>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>>     for (int i = 0; i < len; i++) {
>>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
>> 
>> 
>> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
>> 
>> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comment - Thread::current() never returns nullptr

Changes make sense, thanks!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27231#pullrequestreview-3217009121

From fandreuzzi at openjdk.org  Fri Sep 12 15:39:08 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 15:39:08 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when ran by root user
Message-ID: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>

I noticed this while running the test in a Docker container. Root user ignores write permissions, so the test does not apply.

I propose to skip it if we detect that 'root' is running it.

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

Commit messages:
 - check root

Changes: https://git.openjdk.org/jdk/pull/27261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367552
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27261/head:pull/27261

PR: https://git.openjdk.org/jdk/pull/27261

From mdoerr at openjdk.org  Fri Sep 12 20:46:24 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 12 Sep 2025 20:46:24 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <vt3ZUDr6KvxtqcN3dvYUV6Nrgc3_ctHeZvNrZ7Vyoxg=.101f4eec-fe03-4e1e-a431-b072091c21a6@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

This PR needs an update since `Atomic` has been renamed to `AtomicAccess`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3286765432

From mbaesken at openjdk.org  Sat Sep 13 20:23:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 13 Sep 2025 20:23:24 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive [v6]
In-Reply-To: <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
 <NX7C9W2P1KSoIIKflnJ4jpLcwzbfE8AY5BlTjq3dc3o=.e85bd861-5f1f-46d3-937f-0904413dc7c3@github.com>
Message-ID: <ebluWnYbW_pEFdMl9Gt4rbQeFUrmVd4e_w9ysIgX_GQ=.80ca1dee-7cd1-4d80-9999-bcd83ddd9904@github.com>

On Fri, 12 Sep 2025 07:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
>> we get this message/error :
>> 
>> 
>> Error occurred during initialization of VM
>> Unable to use shared archive.
>> 
>> 
>> The error message could be a little improved, e.g. telling what jsa file is not present .
>> For example
>> 
>> 
>> ./images/jdk/bin/java -Xshare:on -version
>> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
>> Error occurred during initialization of VM
>> Unable to use shared archive (unrecoverable archive loading error).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hint suggested by mdoerr

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/25846#issuecomment-3288802256

From mbaesken at openjdk.org  Sat Sep 13 20:23:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 13 Sep 2025 20:23:25 GMT
Subject: Integrated: 8359423: Improve error message in case of missing jsa
 shared archive
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <4Nh_4LIktdLshNi4fwknxjwY-C8ianK575VLvDI79xI=.936aa3f9-5571-4203-b190-2441a90879f5@github.com>

On Tue, 17 Jun 2025 08:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

This pull request has now been integrated.

Changeset: ef291d2d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef291d2d5d5c6ef9767a218b0f8401a0fb911bb2
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8359423: Improve error message in case of missing jsa shared archive

Reviewed-by: mdoerr, asteiner, eastigeevich

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

PR: https://git.openjdk.org/jdk/pull/25846

From iklam at openjdk.org  Sat Sep 13 20:46:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 13 Sep 2025 20:46:21 GMT
Subject: RFR: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes [v2]
In-Reply-To: <PuICXm2HZXTp_luuoBgCSd8Dv409CTIFtthX1QL-4vE=.29451d62-df08-4ba6-b7c9-46c1268698b6@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
 <PuICXm2HZXTp_luuoBgCSd8Dv409CTIFtthX1QL-4vE=.29451d62-df08-4ba6-b7c9-46c1268698b6@github.com>
Message-ID: <IqKOtyBoYqz_B2Y7Bpjp_2VlS8d1FAjOuAa7wB5lvz8=.cdf1a0fa-c75d-43ae-995d-2ffa3f2c5868@github.com>

On Thu, 11 Sep 2025 22:29:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comment - Thread::current() never returns nullptr
>
> Seems reasonable.

Thanks @liach @dholmes-ora @matias9927 for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27231#issuecomment-3288833912

From iklam at openjdk.org  Sat Sep 13 20:46:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 13 Sep 2025 20:46:23 GMT
Subject: Integrated: 8367475: Incorrect lock usage in
 LambdaFormInvokers::regenerate_holder_classes
In-Reply-To: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
References: <LnY4cAmXhkJ9DL4sESrr4gJBrrzvZRkQK03BPgkoVjc=.d6b5dd9c-1484-4ea5-8676-c41a5c642afb@github.com>
Message-ID: <ul9MgZj3ESVVr45wwRAMJHfbNigosQ5p-BKszss8tgg=.a1e9b0f1-8f0d-449f-acdc-db54343090de@github.com>

On Thu, 11 Sep 2025 17:22:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The assert happens because we attempt to allocate Java objects while holding a mutex:
> 
> 
>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>     for (int i = 0; i < len; i++) {
>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
> 
> 
> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
> 
> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.

This pull request has now been integrated.

Changeset: c85c5cb5
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c85c5cb50e0bd80732af9d45c85fc01032ed332c
Stats:     40 lines in 3 files changed: 23 ins; 8 del; 9 mod

8367475: Incorrect lock usage in LambdaFormInvokers::regenerate_holder_classes

Reviewed-by: dholmes, matsaave, liach

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

PR: https://git.openjdk.org/jdk/pull/27231

From ghan at openjdk.org  Mon Sep 15 01:07:54 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Mon, 15 Sep 2025 01:07:54 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor
Message-ID: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>

Please review this Patch.

**Description:**
Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.

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

Commit messages:
 - 8366925: Improper std::nothrow new expression in NativeHeapTrimmerThread ctor

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

PR: https://git.openjdk.org/jdk/pull/27275

From dzhang at openjdk.org  Mon Sep 15 03:38:51 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 15 Sep 2025 03:38:51 GMT
Subject: RFR: 8367616: RISC-V: Auto-enable Zicboz extension for debug builds
Message-ID: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>

Hi,
Can you help to review this patch? Thanks!

This is a followup change after https://bugs.openjdk.org/browse/JDK-8353829. 
We can add detection and enablement of Zicboz extension.

Testing: hs:tier1 tested with qemu-system(kernel 6.14) with Zicboz extension.

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

Commit messages:
 - 8367616: RISC-V: Auto-enable Zicboz extension for debug builds

Changes: https://git.openjdk.org/jdk/pull/27277/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27277&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367616
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27277.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27277/head:pull/27277

PR: https://git.openjdk.org/jdk/pull/27277

From fyang at openjdk.org  Mon Sep 15 03:46:13 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 15 Sep 2025 03:46:13 GMT
Subject: RFR: 8367616: RISC-V: Auto-enable Zicboz extension for debug
 builds
In-Reply-To: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
References: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
Message-ID: <m4iUPriF7bP0Q-6sgBLPa_4oveHKAZv_2wEgtFgw7bc=.4e6e5835-784d-4a7d-b8d9-9867ef8ac7ae@github.com>

On Mon, 15 Sep 2025 03:31:36 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> This is a followup change after https://bugs.openjdk.org/browse/JDK-8353829. 
> We can add detection and enablement of Zicboz extension.
> 
> Testing: hs:tier1 tested with qemu-system(kernel 6.14) with Zicboz extension.

Thanks!

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27277#pullrequestreview-3222821774

From kbarrett at openjdk.org  Mon Sep 15 04:22:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 04:22:11 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
Message-ID: <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>

On Fri, 12 Sep 2025 08:08:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
>> 
>> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
>> 
>> I will verify that this still builds on the platform that I can easily build.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix zero

Changes requested by kbarrett (Reviewer).

src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 27:

> 25: 
> 26: #include "asm/assembler.inline.hpp"
> 27: #include "atomicAccess_linux_zero.hpp"

The platform-specific atomic[Access] headers were never really intended for direct inclusion.
I think it's being included here to get atomic_copy64. But there is code in this file that I think
*should* be using `AtomicAccess`. But that's a pre-existing issue that doesn't need to be dealt
with in this PR. But I'd prefer this included `atomicAccess.hpp`.

src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 27:

> 25: 
> 26: #include "asm/assembler.inline.hpp"
> 27: #include "atomicAccess_linux_zero.hpp"

It looks like `os_bsd_zero.cpp` has the same issue, but doesn't seem to be touched in this PR?

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

PR Review: https://git.openjdk.org/jdk/pull/27245#pullrequestreview-3222859554
PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2347840944
PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2347842074

From kbarrett at openjdk.org  Mon Sep 15 04:30:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 04:30:11 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
 <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
Message-ID: <4VETLTffDwyeuvC_Pm5ocKk5XtkkIoUlIJLZcvyq-bE=.ed45cd94-0326-477c-bbff-24a8319d560c@github.com>

On Mon, 15 Sep 2025 04:16:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix zero
>
> src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 27:
> 
>> 25: 
>> 26: #include "asm/assembler.inline.hpp"
>> 27: #include "atomicAccess_linux_zero.hpp"
> 
> The platform-specific atomic[Access] headers were never really intended for direct inclusion.
> I think it's being included here to get atomic_copy64. But there is code in this file that I think
> *should* be using `AtomicAccess`. But that's a pre-existing issue that doesn't need to be dealt
> with in this PR. But I'd prefer this included `atomicAccess.hpp`.

Or maybe the definition of `atomic_copy64` for linux-zero should be moved to `os_linux_zero.cpp`, which
I think would be consistent with all of the other definitions/uses of that function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2347848918

From stefank at openjdk.org  Mon Sep 15 06:19:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Sep 2025 06:19:20 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v4]
In-Reply-To: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
Message-ID: <qbHSzaA4M3ZbcneCBl4I8ne2PfZ9EMtzAw9HgNNlG0k=.009720af-fdb2-4916-92ab-18035b9f827d@github.com>

> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
> 
> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
> 
> I will verify that this still builds on the platform that I can easily build.

Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:

 - Update include in os_bsd_zero.cpp
 - Update include in os_linux_zero.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27245/files
  - new: https://git.openjdk.org/jdk/pull/27245/files/30e51731..54e7b62d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27245&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27245&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/27245

From stefank at openjdk.org  Mon Sep 15 06:19:23 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Sep 2025 06:19:23 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
 <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
Message-ID: <7VDGtEvf8sPI_yeiO7h2Gd0frni-a2AmzWdPaj-0OOw=.00819c5b-01e2-4ab0-b070-dec5003716c8@github.com>

On Mon, 15 Sep 2025 04:18:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix zero
>
> Changes requested by kbarrett (Reviewer).

@kimbarrett I've updated the zero files and compiled locally on linux and mac.

> src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 27:
> 
>> 25: 
>> 26: #include "asm/assembler.inline.hpp"
>> 27: #include "atomicAccess_linux_zero.hpp"
> 
> It looks like `os_bsd_zero.cpp` has the same issue, but doesn't seem to be touched in this PR?

Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27245#issuecomment-3290633314
PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2347968924

From stefank at openjdk.org  Mon Sep 15 06:19:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Sep 2025 06:19:25 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <4VETLTffDwyeuvC_Pm5ocKk5XtkkIoUlIJLZcvyq-bE=.ed45cd94-0326-477c-bbff-24a8319d560c@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
 <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
 <4VETLTffDwyeuvC_Pm5ocKk5XtkkIoUlIJLZcvyq-bE=.ed45cd94-0326-477c-bbff-24a8319d560c@github.com>
Message-ID: <9im5fWY1xNnLOV8E_mDeBWZbohdcwUqkOnPulpqd90M=.d37af902-5c94-4a67-a413-c6e47f30f366@github.com>

On Mon, 15 Sep 2025 04:27:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 27:
>> 
>>> 25: 
>>> 26: #include "asm/assembler.inline.hpp"
>>> 27: #include "atomicAccess_linux_zero.hpp"
>> 
>> The platform-specific atomic[Access] headers were never really intended for direct inclusion.
>> I think it's being included here to get atomic_copy64. But there is code in this file that I think
>> *should* be using `AtomicAccess`. But that's a pre-existing issue that doesn't need to be dealt
>> with in this PR. But I'd prefer this included `atomicAccess.hpp`.
>
> Or maybe the definition of `atomic_copy64` for linux-zero should be moved to `os_linux_zero.cpp`, which
> I think would be consistent with all of the other definitions/uses of that function.

I've updated the file to use atomicAccess.hpp, but I'll let someone else make the move of the function if that is deemed to be the right thing to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2347968800

From dholmes at openjdk.org  Mon Sep 15 07:18:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Sep 2025 07:18:19 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v4]
In-Reply-To: <ES-BBbjqHk6OBpc__DHUJCtlI0b9dNRoDz_cO6UAPTM=.73baf150-3dea-4eda-898a-1d9e1cd789b8@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <ES-BBbjqHk6OBpc__DHUJCtlI0b9dNRoDz_cO6UAPTM=.73baf150-3dea-4eda-898a-1d9e1cd789b8@github.com>
Message-ID: <ZM2juVUWZH5ZgXjfHba3mBYmnqMNQZgDGxquP5fvJ6M=.2965f5ad-5867-4e09-be42-421577e08411@github.com>

On Fri, 12 Sep 2025 08:33:56 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
>> Specific casts are used to avoid UBSAN error.
>> 
>> Tests:
>> linux-x64-debug: tier1 passed
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment fixed

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3223203619

From fjiang at openjdk.org  Mon Sep 15 07:45:45 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 15 Sep 2025 07:45:45 GMT
Subject: RFR: 8367616: RISC-V: Auto-enable Zicboz extension for debug
 builds
In-Reply-To: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
References: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
Message-ID: <5FwoQcicJusb-3MKSMN63LHQB6lhNSNKvnFypWjkS5Y=.c5eb1f28-fc72-4dc5-92fe-0494c31d237d@github.com>

On Mon, 15 Sep 2025 03:31:36 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> This is a followup change after https://bugs.openjdk.org/browse/JDK-8353829. 
> We can add detection and enablement of Zicboz extension.
> 
> Testing: hs:tier1 tested with qemu-system(kernel 6.14) with Zicboz extension.

Looks good!

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

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27277#pullrequestreview-3223287025

From jbechberger at openjdk.org  Mon Sep 15 09:31:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 15 Sep 2025 09:31:27 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning [v2]
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <lUsJpO0Xk9mPoJOvexhw7BN1JT1tNvFf7YnFIuxS9Q0=.49185bd6-cf12-4b3b-9873-35d09931d05c@github.com>

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into parttimenerd_fix_startup
 - Fix startup message printing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26957/files
  - new: https://git.openjdk.org/jdk/pull/26957/files/95c47b2a..56cef57f

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

  Stats: 46693 lines in 1755 files changed: 26974 ins; 11155 del; 8564 mod
  Patch: https://git.openjdk.org/jdk/pull/26957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26957/head:pull/26957

PR: https://git.openjdk.org/jdk/pull/26957

From jbechberger at openjdk.org  Mon Sep 15 09:32:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 15 Sep 2025 09:32:54 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning [v3]
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <JJKhKwC29uyPBTdUGTIi6OZB4VlYYqu6LjhMeIJlqKQ=.f9f46a9d-a9e0-4224-947d-72d1f3dece08@github.com>

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Rename Atomic:: to AtomicAccess::

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26957/files
  - new: https://git.openjdk.org/jdk/pull/26957/files/56cef57f..4b827459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26957&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26957&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26957/head:pull/26957

PR: https://git.openjdk.org/jdk/pull/26957

From ayang at openjdk.org  Mon Sep 15 10:24:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Sep 2025 10:24:10 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor
In-Reply-To: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
Message-ID: <2Zstvlb712awuZKIpz2it6qGXG12rBok1qV6HkRJhIA=.63621c99-e76f-46dc-9997-49bcf840914e@github.com>

On Mon, 15 Sep 2025 01:01:17 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Please review this Patch.
> 
> **Description:**
> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.

Why does the init of `_lock` use `std::nothrow`? `PaddedMonitor` is `CHeapObj` -- wouldn't the default `new` operator invoke the exit-on-oom?

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

PR Review: https://git.openjdk.org/jdk/pull/27275#pullrequestreview-3223899152

From jsjolen at openjdk.org  Mon Sep 15 11:28:20 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 15 Sep 2025 11:28:20 GMT
Subject: RFR: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter [v3]
In-Reply-To: <1OaakMl3Kt0xF7zuTwTkmYv2V_4cMmv32bwjSssGZyM=.3768a258-b297-4c5e-a13c-55b512c7bc7a@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
 <1OaakMl3Kt0xF7zuTwTkmYv2V_4cMmv32bwjSssGZyM=.3768a258-b297-4c5e-a13c-55b512c7bc7a@github.com>
Message-ID: <mRW0__wafKIl-wVJ_zfkXC8B5XVSvzMj_kOsVK5yijY=.00323193-1330-4858-b1d7-9811635f9975@github.com>

On Fri, 12 Sep 2025 09:16:47 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
>> 
>> Passes tier1.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/missing-locks' into missing-locks
>  - Merge lock blocks

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27038#issuecomment-3291667006

From jsjolen at openjdk.org  Mon Sep 15 11:28:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 15 Sep 2025 11:28:21 GMT
Subject: Integrated: 8366658: Add missing locks when accessing the
 VirtualMemoryTracker instance in tests and MemMapPrinter
In-Reply-To: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
References: <48SsPZvXdBi5z-lH98GOwg8Aic978pwJKI-1tF_mxL8=.7092dceb-6ef2-45ee-bc0d-90477f00e6ee@github.com>
Message-ID: <Q1dHlzl3NkQY7atSlJMwsILHETwYHJQdm6FCFRS_8so=.ceb15f5e-6834-498d-8812-9554b83a84b3@github.com>

On Tue, 2 Sep 2025 07:07:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR adds the missing locks for the tests and MemMapPrinter, also fixes a small bug in `walk_virtual_memory`. See inline review comments.
> 
> Passes tier1.

This pull request has now been integrated.

Changeset: a7dc011a
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7dc011ac4fec73d686661b1bb6969c7135982f2
Stats:     50 lines in 8 files changed: 23 ins; 1 del; 26 mod

8366658: Add missing locks when accessing the VirtualMemoryTracker instance in tests and MemMapPrinter

Reviewed-by: azafari, phubner

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

PR: https://git.openjdk.org/jdk/pull/27038

From phubner at openjdk.org  Mon Sep 15 13:12:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 13:12:32 GMT
Subject: RFR: 8366884: NMT fails with MallocLimit: reached category
 "mtCompiler" limit
In-Reply-To: <bs7bvViPRH0l5vATEy7vssHhJ1Rm6GEhbBm3Fs53CH0=.c6f7cc50-0883-4115-a770-6c9b1c305788@github.com>
References: <bs7bvViPRH0l5vATEy7vssHhJ1Rm6GEhbBm3Fs53CH0=.c6f7cc50-0883-4115-a770-6c9b1c305788@github.com>
Message-ID: <mTBBEsg9AORy3SQgzQQNt34hfBjY1yeEwBXy8RmRBdk=.ebf69f54-b947-4316-97c1-9dcee935f0ef@github.com>

On Fri, 12 Sep 2025 07:31:17 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JTREG test expects that jvm exits with error on malloc-limit reached. JVM reports this and exits but test is timed out before reading the output.
> The timeout value for the test is set explicitly to 480. 
> 
> Tested couple of 100 times in mach5.

LGTM, thanks for doing this.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/27246#pullrequestreview-3224534498

From phubner at openjdk.org  Mon Sep 15 13:31:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 13:31:08 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when ran by root user
In-Reply-To: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
Message-ID: <hQhINcJqnDbeYeJUl_PB9zxOEmTkbuu_fK33Pmjjx1Y=.24832eff-d719-44be-98db-ba3e15648e9b@github.com>

On Fri, 12 Sep 2025 15:30:49 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
> 
> I propose to skip it if we detect that 'root' is running it, should be a trivial change.

Thanks for fixing.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/27261#pullrequestreview-3224617356

From ayang at openjdk.org  Mon Sep 15 13:31:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 15 Sep 2025 13:31:55 GMT
Subject: RFR: 8263476: Use reserved memory for stack guard pages [v6]
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <hqzFcHRj33dNip5L6AJdbtT9G75mUC4Rz0fmYTPh1BA=.9ffc77c9-e459-4714-860d-5bc48014e820@github.com>

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: ~tier1-3~ tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into no-commit-stack-guard-page
 - Merge branch 'master' into no-commit-stack-guard-page
 - Merge branch 'master' into no-commit-stack-guard-page
 - review
 - review
 - Merge branch 'master' into no-commit-stack-guard-page
 - no-commit-stack-guard-page

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26571/files
  - new: https://git.openjdk.org/jdk/pull/26571/files/5e4de066..8926dc1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26571&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26571&range=04-05

  Stats: 54615 lines in 1919 files changed: 32173 ins; 12898 del; 9544 mod
  Patch: https://git.openjdk.org/jdk/pull/26571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26571/head:pull/26571

PR: https://git.openjdk.org/jdk/pull/26571

From ghan at openjdk.org  Mon Sep 15 14:12:59 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Mon, 15 Sep 2025 14:12:59 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor
In-Reply-To: <2Zstvlb712awuZKIpz2it6qGXG12rBok1qV6HkRJhIA=.63621c99-e76f-46dc-9997-49bcf840914e@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <2Zstvlb712awuZKIpz2it6qGXG12rBok1qV6HkRJhIA=.63621c99-e76f-46dc-9997-49bcf840914e@github.com>
Message-ID: <8xlZbah-1HBFO39qpssnZT2ylfNkYqSc75uajGq-hmw=.9a0c28dc-89ba-4c97-ba11-36c33bb23dd9@github.com>

On Mon, 15 Sep 2025 10:21:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this Patch.
>> 
>> **Description:**
>> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.
>
> Why does the init of `_lock` use `std::nothrow`? `PaddedMonitor` is `CHeapObj` -- wouldn't the default `new` operator invoke the exit-on-oom?

Hi @albertnetymk, i?m actually not sure about the original author?s intent for using new (std::nothrow) here. In my change I kept the same allocation style. The reason I didn?t switch to the default CHeapObj operator new (which exits on OOM) is that it would terminate the VM with a generic OOM message.
By keeping std::nothrow and explicitly checking for nullptr, I can emit a clearer, more specific error message before exiting.

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

PR Comment: https://git.openjdk.org/jdk/pull/27275#issuecomment-3292372163

From coleenp at openjdk.org  Mon Sep 15 14:25:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Sep 2025 14:25:29 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

This looks great.  You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class).

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3224893210

From phubner at openjdk.org  Mon Sep 15 14:25:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 14:25:30 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <HXRziQ5kz7iu8lLRiy7bK3QXgXw0dfkKJecp2vUB8pQ=.66d83f6f-8889-4671-8cb9-72a72030fcb9@github.com>
Message-ID: <3NcFIVzB54ClBeKBOMpzHFt9gHz-VY5tZGflXHpAXVQ=.f69ec18a-1732-404d-9f0a-c34af33698f1@github.com>

On Mon, 15 Sep 2025 14:19:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class).

Apologies, I've updated the PR description accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292440414

From liach at openjdk.org  Mon Sep 15 15:08:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Sep 2025 15:08:59 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field?

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292670063

From phubner at openjdk.org  Mon Sep 15 15:25:54 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 15:25:54 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com>
Message-ID: <BFAPiKK3-gwEPW9pXhaQwlH4SPrfS_pt3UxcTysRIeo=.fcbfb57f-7ead-42d5-8dad-2383f97022f8@github.com>

On Mon, 15 Sep 2025 15:05:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field?

I'm not sure, I came across this file as well and could not determine if it was an old artefact or not. I had a look at the log message and cross-referenced with HotSpot, and I also went digging in the commit messages, but I could not find anything fruitful. Considering it uses a wildcard and does not reference `sun.reflect.ConstantPool` or `jdk.internal.reflect.ConstantPool` leads me to believe this might be something else, most likely dead code. Many tiers of tests pass. I'm happy to open an issue if you think it's worth looking into.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292742093

From phubner at openjdk.org  Mon Sep 15 15:54:47 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 15:54:47 GMT
Subject: RFR: 8366229: runtime/Thread/TooSmallStackSize.java runs with all
 collectors
Message-ID: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>

Hi all,

This change forces the `TooSmallStackSize.java` test to run on flagless VMs. Previously, this could get influenced by GC choice, whose flags were never propagated to the subprocess.

Testing: tier 1.

N.B.: Please ignore my fork's branch name, I copied and pasted the wrong ID.

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

Commit messages:
 - Require flagless VM for TooSmallStackSize.java.

Changes: https://git.openjdk.org/jdk/pull/27297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366229
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27297/head:pull/27297

PR: https://git.openjdk.org/jdk/pull/27297

From liach at openjdk.org  Mon Sep 15 16:06:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Sep 2025 16:06:30 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <VR3FYJNMBflb00WNc1EEnuv5Wvd1CjjPyWsUTngyGBI=.d97fa857-784d-4ddc-b0de-0e4df5ff35b7@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

The removal of this field looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225353180

From coleenp at openjdk.org  Mon Sep 15 16:06:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Sep 2025 16:06:31 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292895168

From jsjolen at openjdk.org  Mon Sep 15 17:44:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 15 Sep 2025 17:44:39 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Tmcu3Qk7HElp8gKdra-WjnKvtkfkoQY5ofztZ0H7JfY=.dac26a7d-d9fc-4836-9e60-4ce3a0b3cefd@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Looks good to me!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225668786

From amenkov at openjdk.org  Mon Sep 15 19:15:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 15 Sep 2025 19:15:26 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <JqcPL4AE_globSRAPoABYNmDI2ABrR56XPOUrgzMZMo=.489d7b11-a2f8-4ea6-a185-6b0e9903a1ce@github.com>

On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Looks good
I was sure HeapDumper also uses FilteredJavaFieldStream to exclude constantPoolOop field, but it doesn't (I don't remember when it changed and why we didn't have issue with it)

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225947841

From kbarrett at openjdk.org  Mon Sep 15 19:50:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 19:50:33 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor
In-Reply-To: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
Message-ID: <ZffUX4-MYQc0t-Srj5eDzbgBQLAHVhDqxgjmbEJrEZM=.d6dc5fa4-b526-4f79-aaca-33b1340ecc4a@github.com>

On Mon, 15 Sep 2025 01:01:17 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Please review this Patch.
> 
> **Description:**
> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/trimNativeHeap.cpp line 174:

> 172:         vm_exit_out_of_memory(0, OOM_MALLOC_ERROR,
> 173:                               "Failed to allocate NativeHeapTrimmer_lock");
> 174:     }

There are a lot of places where, when creating a new thread in the VM, we try
to provide a soft landing when the creation fails (due to OOM or otherwise).
That tends to be more of a thing for asynchronously created VM threads, and
perhaps less so for those created at startup. I'm guessing this is one of the
latter. So I'm guessing the rationale for using the nothrow allocation of the
mutex was a botched attempt at providing such a soft landing. That code was in
the initial commit of the change that added this code, and there was no
discussion of it in the PR. On the other hand, the change author is available
to be asked: @tstuefe ?

It's also relevant that if the `os::create_thread` fails then we seem to just
quietly drop the whole tracking and trimming thing. To be consistent with that
one might keep the existing nothrow lock allocation and just change that
condition for starting the thread to first check for non-null `_lock`.

Basically, I think it should either try harder to not abort the application,
or should just do the simple thing of not using nothrow allocation for the
mutex. Adding code for a "better" error message for the abort doesn't seem
worthwhile to me.

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

PR Review: https://git.openjdk.org/jdk/pull/27275#pullrequestreview-3226040167
PR Review Comment: https://git.openjdk.org/jdk/pull/27275#discussion_r2349945663

From dcubed at openjdk.org  Mon Sep 15 23:30:11 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Sep 2025 23:30:11 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when ran by root user
In-Reply-To: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
Message-ID: <o_D2fJjlTb7M3W8JoJSu8icTypEze2K3n2SJg_bRkn8=.f8b2743e-6486-41ca-83be-c4fa704da437@github.com>

On Fri, 12 Sep 2025 15:30:49 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
> 
> I propose to skip it if we detect that 'root' is running it, should be a trivial change.

I changed the bug synopsis from 'ran' to 'run'. Please update the PR's title.
The easiest way to do that is: `/issue JDK-8367552`

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

PR Comment: https://git.openjdk.org/jdk/pull/27261#issuecomment-3294311002

From dcubed at openjdk.org  Mon Sep 15 23:35:16 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Sep 2025 23:35:16 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when ran by root user
In-Reply-To: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
Message-ID: <XYQiUIQyzEtAcUmYk9YgvbEHwPW4SUjB34_wJnOHk-s=.0c9bfca9-33b0-4fb2-97af-7635523eb024@github.com>

On Fri, 12 Sep 2025 15:30:49 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
> 
> I propose to skip it if we detect that 'root' is running it, should be a trivial change.

Changes requested by dcubed (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 145:

> 143:         }
> 144:         if (Platform.isRoot()) {
> 145:             throw new jtreg.SkippedException("Write permissions do not apply to root user");

Perhaps:

throw new jtreg.SkippedException("Test skipped when executed by root user.");

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

PR Review: https://git.openjdk.org/jdk/pull/27261#pullrequestreview-3226600884
PR Review Comment: https://git.openjdk.org/jdk/pull/27261#discussion_r2350321907

From fandreuzzi at openjdk.org  Mon Sep 15 23:45:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 15 Sep 2025 23:45:19 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
 [v2]
In-Reply-To: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
Message-ID: <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>

> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
> 
> I propose to skip it if we detect that 'root' is running it, should be a trivial change.

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27261/files
  - new: https://git.openjdk.org/jdk/pull/27261/files/373f0c3f..c7e69cea

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27261/head:pull/27261

PR: https://git.openjdk.org/jdk/pull/27261

From fandreuzzi at openjdk.org  Mon Sep 15 23:45:21 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 15 Sep 2025 23:45:21 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
 [v2]
In-Reply-To: <XYQiUIQyzEtAcUmYk9YgvbEHwPW4SUjB34_wJnOHk-s=.0c9bfca9-33b0-4fb2-97af-7635523eb024@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
 <XYQiUIQyzEtAcUmYk9YgvbEHwPW4SUjB34_wJnOHk-s=.0c9bfca9-33b0-4fb2-97af-7635523eb024@github.com>
Message-ID: <Nu3xqZufueMDkdER7hktTxcNstSufDewbH1ippE6WOk=.5a73bfc7-39f3-4c8c-b6b4-5b01b765393f@github.com>

On Mon, 15 Sep 2025 23:32:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 145:
> 
>> 143:         }
>> 144:         if (Platform.isRoot()) {
>> 145:             throw new jtreg.SkippedException("Write permissions do not apply to root user");
> 
> Perhaps:
> 
> throw new jtreg.SkippedException("Test skipped when executed by root user.");

Suggestion:

            throw new jtreg.SkippedException("Test skipped when executed by root user.");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27261#discussion_r2350332840

From kbarrett at openjdk.org  Mon Sep 15 23:46:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 23:46:10 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v4]
In-Reply-To: <qbHSzaA4M3ZbcneCBl4I8ne2PfZ9EMtzAw9HgNNlG0k=.009720af-fdb2-4916-92ab-18035b9f827d@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <qbHSzaA4M3ZbcneCBl4I8ne2PfZ9EMtzAw9HgNNlG0k=.009720af-fdb2-4916-92ab-18035b9f827d@github.com>
Message-ID: <q923snt9zQHWUMZVCOXpVFW-xdeBBjOGgTGARi7VhKk=.645e8969-de87-4798-a91d-1eb90d27f105@github.com>

On Mon, 15 Sep 2025 06:19:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> JDK-8367014 renamed the class Atomic to AtomicAccess and renamed atomic.hpp to atomicAccess.hpp. I propose that we also rename the platform-dependent headers that implement the AtomicAccess support to be named atomicAccess_<os>_<arch>.hpp.
>> 
>> Note that I left atomic_aarch64.hpp and atomic_linux_aarch64.S intact since they clear, external usages outside of the AtomicAccess class.
>> 
>> I will verify that this still builds on the platform that I can easily build.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update include in os_bsd_zero.cpp
>  - Update include in os_linux_zero.cpp

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27245#pullrequestreview-3226621479

From kbarrett at openjdk.org  Mon Sep 15 23:46:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 23:46:12 GMT
Subject: RFR: 8367486: Change prefix for platform-dependent AtomicAccess
 files [v3]
In-Reply-To: <9im5fWY1xNnLOV8E_mDeBWZbohdcwUqkOnPulpqd90M=.d37af902-5c94-4a67-a413-c6e47f30f366@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
 <bQDAZQ7GwwTAkkkWt2R-q9zBxKjVP2QftzGlw75jivI=.9f119a94-a49d-4928-bb64-3b5a685c2575@github.com>
 <RWTfHG30laI7DSdL0d6sZbN9Ap50reHx22ZHtCUw-Yc=.328cab85-171d-4dca-8ad8-ed872f4642d1@github.com>
 <4VETLTffDwyeuvC_Pm5ocKk5XtkkIoUlIJLZcvyq-bE=.ed45cd94-0326-477c-bbff-24a8319d560c@github.com>
 <9im5fWY1xNnLOV8E_mDeBWZbohdcwUqkOnPulpqd90M=.d37af902-5c94-4a67-a413-c6e47f30f366@github.com>
Message-ID: <F34oGtDc9aSoWLla1oRnh3U1Ia6W325JArpxgs4V6ho=.97ab75bf-c0ab-4f69-b489-ccd8801d9a4c@github.com>

On Mon, 15 Sep 2025 06:14:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Or maybe the definition of `atomic_copy64` for linux-zero should be moved to `os_linux_zero.cpp`, which
>> I think would be consistent with all of the other definitions/uses of that function.
>
> I've updated the file to use atomicAccess.hpp, but I'll let someone else make the move of the function if that is deemed to be the right thing to do.

https://bugs.openjdk.org/browse/JDK-8367717 "Cleanup atomic_copy64"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27245#discussion_r2350335610

From dcubed at openjdk.org  Tue Sep 16 00:14:39 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Sep 2025 00:14:39 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
 [v2]
In-Reply-To: <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
 <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
Message-ID: <3nUR7baNJ-LuFV7wpQamO3rS9nl-7lYBIvFpTby94Vk=.9de9a823-bb78-4d2e-adf1-45dab02590b2@github.com>

On Mon, 15 Sep 2025 23:45:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
>> 
>> I propose to skip it if we detect that 'root' is running it, should be a trivial change.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for updating the mesg.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27261#pullrequestreview-3226662505

From fandreuzzi at openjdk.org  Tue Sep 16 00:26:12 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 00:26:12 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
In-Reply-To: <o_D2fJjlTb7M3W8JoJSu8icTypEze2K3n2SJg_bRkn8=.f8b2743e-6486-41ca-83be-c4fa704da437@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
 <o_D2fJjlTb7M3W8JoJSu8icTypEze2K3n2SJg_bRkn8=.f8b2743e-6486-41ca-83be-c4fa704da437@github.com>
Message-ID: <UDlm8K0R6iRwLu5CKjMla_vfAw-gvNDdpB44OsaoLzA=.5c2d2863-2375-4ca1-b94d-4282069067f1@github.com>

On Mon, 15 Sep 2025 23:27:03 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
>> 
>> I propose to skip it if we detect that 'root' is running it, should be a trivial change.
>
> I changed the bug synopsis from 'ran' to 'run'. Please update the PR's title.
> The easiest way to do that is: `/issue JDK-8367552`

Thanks for the review @dcubed-ojdk and @Arraying

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

PR Comment: https://git.openjdk.org/jdk/pull/27261#issuecomment-3294413656

From duke at openjdk.org  Tue Sep 16 00:26:14 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 00:26:14 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
 [v2]
In-Reply-To: <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
 <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
Message-ID: <b6YojoSWqNg-52tdxf9hJZpV-vZFYjMMOcdGbG1l0Ug=.e2d20d4e-f23b-4e62-ae30-c3f495681ea1@github.com>

On Mon, 15 Sep 2025 23:45:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
>> 
>> I propose to skip it if we detect that 'root' is running it, should be a trivial change.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

@fandreuz 
Your change (at version c7e69ceacc7482adbdeba490580b1858e40e6f5d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27261#issuecomment-3294418588

From ghan at openjdk.org  Tue Sep 16 01:00:01 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 16 Sep 2025 01:00:01 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
Message-ID: <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>

> Please review this Patch.
> 
> **Description:**
> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.

Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:

  Update trimNativeHeap.cpp
  
  remove std::nothrow and rely on the default new handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27275/files
  - new: https://git.openjdk.org/jdk/pull/27275/files/45a18bc6..8e2df85f

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

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27275/head:pull/27275

PR: https://git.openjdk.org/jdk/pull/27275

From ghan at openjdk.org  Tue Sep 16 01:03:15 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 16 Sep 2025 01:03:15 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <ZffUX4-MYQc0t-Srj5eDzbgBQLAHVhDqxgjmbEJrEZM=.d6dc5fa4-b526-4f79-aaca-33b1340ecc4a@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <ZffUX4-MYQc0t-Srj5eDzbgBQLAHVhDqxgjmbEJrEZM=.d6dc5fa4-b526-4f79-aaca-33b1340ecc4a@github.com>
Message-ID: <-H5h314zVBPIChN4oOqi50liSAZH0Z59UdsfWKEMTYc=.197c3841-3854-45fa-a489-c734ad6d7979@github.com>

On Mon, 15 Sep 2025 19:46:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update trimNativeHeap.cpp
>>   
>>   remove std::nothrow and rely on the default new handling
>
> src/hotspot/share/runtime/trimNativeHeap.cpp line 174:
> 
>> 172:         vm_exit_out_of_memory(0, OOM_MALLOC_ERROR,
>> 173:                               "Failed to allocate NativeHeapTrimmer_lock");
>> 174:     }
> 
> There are a lot of places where, when creating a new thread in the VM, we try
> to provide a soft landing when the creation fails (due to OOM or otherwise).
> That tends to be more of a thing for asynchronously created VM threads, and
> perhaps less so for those created at startup. I'm guessing this is one of the
> latter. So I'm guessing the rationale for using the nothrow allocation of the
> mutex was a botched attempt at providing such a soft landing. That code was in
> the initial commit of the change that added this code, and there was no
> discussion of it in the PR. On the other hand, the change author is available
> to be asked: @tstuefe ?
> 
> It's also relevant that if the `os::create_thread` fails then we seem to just
> quietly drop the whole tracking and trimming thing. To be consistent with that
> one might keep the existing nothrow lock allocation and just change that
> condition for starting the thread to first check for non-null `_lock`.
> 
> Basically, I think it should either try harder to not abort the application,
> or should just do the simple thing of not using nothrow allocation for the
> mutex. Adding code for a "better" error message for the abort doesn't seem
> worthwhile to me.

Hi @kimbarrett , thank you for the detailed explanation. I agree ? I?ll go with the simpler option and just remove the nothrow allocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27275#discussion_r2350417918

From dzhang at openjdk.org  Tue Sep 16 01:14:26 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 16 Sep 2025 01:14:26 GMT
Subject: RFR: 8367616: RISC-V: Auto-enable Zicboz extension for debug
 builds
In-Reply-To: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
References: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
Message-ID: <jtyPK4j1cS7RYIVpvz4eb00w8Myd7zA8yyDRJiyKNUY=.ce406282-2101-4561-948f-3ad109fe68e2@github.com>

On Mon, 15 Sep 2025 03:31:36 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> This is a followup change after https://bugs.openjdk.org/browse/JDK-8353829. 
> We can add detection and enablement of Zicboz extension.
> 
> Testing: hs:tier1 tested with qemu-system(kernel 6.14) with Zicboz extension.

Thanks all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27277#issuecomment-3294487885

From dzhang at openjdk.org  Tue Sep 16 01:14:26 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 16 Sep 2025 01:14:26 GMT
Subject: Integrated: 8367616: RISC-V: Auto-enable Zicboz extension for debug
 builds
In-Reply-To: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
References: <tT9ZRSYyuJ77uEZ4FJCGo_2zvFgosJ6PN7621m4Y2Vo=.6471ebe5-f51c-45ac-a54d-e210d1a029ff@github.com>
Message-ID: <zk11tn0hYaov2CRpKpPA5pByro88n_7Bz8iLnHYkadM=.46b9346b-1945-4545-9343-2c0b817a3864@github.com>

On Mon, 15 Sep 2025 03:31:36 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> This is a followup change after https://bugs.openjdk.org/browse/JDK-8353829. 
> We can add detection and enablement of Zicboz extension.
> 
> Testing: hs:tier1 tested with qemu-system(kernel 6.14) with Zicboz extension.

This pull request has now been integrated.

Changeset: 90e81c2b
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90e81c2bee86f404250fb9b833d43b18190b5272
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8367616: RISC-V: Auto-enable Zicboz extension for debug builds

Reviewed-by: fyang, fjiang

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

PR: https://git.openjdk.org/jdk/pull/27277

From dholmes at openjdk.org  Tue Sep 16 02:47:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Sep 2025 02:47:13 GMT
Subject: RFR: 8366229: runtime/Thread/TooSmallStackSize.java runs with all
 collectors
In-Reply-To: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>
References: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>
Message-ID: <7CTt5DcuXLK2v1lmyZJQfhOwnDoKNG45clxTrDCpSTI=.c0b96c06-0602-4a50-8854-e925f6d95044@github.com>

On Mon, 15 Sep 2025 15:39:16 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This change forces the `TooSmallStackSize.java` test to run on flagless VMs. Previously, this could get influenced by GC choice, whose flags were never propagated to the subprocess.
> 
> Testing: tier 1.
> 
> N.B.: Please ignore my fork's branch name, I copied and pasted the wrong ID.

Yes you should always require `flagless` when using `createLimitedTestJavaProcessBuilder`.

Thanks for cleaning it up.

PS. I consider this a trivial fix.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27297#pullrequestreview-3226869663
PR Comment: https://git.openjdk.org/jdk/pull/27297#issuecomment-3294645653

From dholmes at openjdk.org  Tue Sep 16 03:23:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Sep 2025 03:23:19 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
Message-ID: <EVoaPYdmVGFH1s-ZHt19EWC8Npzkutp78GCoXW05i2g=.8749dd3d-6cba-4910-80a8-27089033f885@github.com>

On Tue, 16 Sep 2025 01:00:01 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this Patch.
>> 
>> **Description:**
>> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update trimNativeHeap.cpp
>   
>   remove std::nothrow and rely on the default new handling

So we will now abort the VM if the allocation of the monitor fails. That seems okay as we are late in the VM initialization process and so if we have exhausted memory we are not going much further. regardless.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27275#pullrequestreview-3226938193

From kbarrett at openjdk.org  Tue Sep 16 06:52:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Sep 2025 06:52:40 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
Message-ID: <PLc8R5_30bIqESugeayJWznWRVXzY6P-tSoUkS32dSM=.7bbb576d-2da3-431d-aa54-5b3a6f28af5d@github.com>

On Tue, 16 Sep 2025 01:00:01 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this Patch.
>> 
>> **Description:**
>> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update trimNativeHeap.cpp
>   
>   remove std::nothrow and rely on the default new handling

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27275#pullrequestreview-3227833340

From duke at openjdk.org  Tue Sep 16 06:58:23 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 06:58:23 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
Message-ID: <Qb0ZR0LsqUwxURvD_IOYvWdqSc8MkuHMc9QmHzdF7cg=.00badc1a-a8d1-4ea5-a4c8-cb0c0bcd66cf@github.com>

On Tue, 16 Sep 2025 01:00:01 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this Patch.
>> 
>> **Description:**
>> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update trimNativeHeap.cpp
>   
>   remove std::nothrow and rely on the default new handling

@hgqxjj 
Your change (at version 8e2df85f41fb13075e3da7e06645d6e62a15f3ca) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27275#issuecomment-3295984297

From ghan at openjdk.org  Tue Sep 16 07:48:49 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 16 Sep 2025 07:48:49 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <EVoaPYdmVGFH1s-ZHt19EWC8Npzkutp78GCoXW05i2g=.8749dd3d-6cba-4910-80a8-27089033f885@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
 <EVoaPYdmVGFH1s-ZHt19EWC8Npzkutp78GCoXW05i2g=.8749dd3d-6cba-4910-80a8-27089033f885@github.com>
Message-ID: <AKmll9W48n30fdZxyqpMRzfXCnyjz2EB3foTD5J2J8k=.fcbcac62-617a-40c1-bc89-fbd7497ef599@github.com>

On Tue, 16 Sep 2025 03:20:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update trimNativeHeap.cpp
>>   
>>   remove std::nothrow and rely on the default new handling
>
> So we will now abort the VM if the allocation of the monitor fails. That seems okay as we are late in the VM initialization process and so if we have exhausted memory we are not going much further. regardless.

@dholmes-ora @kimbarrett Thank you for your approval .
 I've integrated this change, could you please kindly sponsor it ? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27275#issuecomment-3296327473

From ayang at openjdk.org  Tue Sep 16 07:55:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Sep 2025 07:55:45 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
Message-ID: <DUowxMTwTyAfDo9tKaridInNVjd3U4MSUJffXoBkFbY=.dd6d597d-85ad-46f5-97da-d9cd46ecd9e3@github.com>

On Tue, 16 Sep 2025 01:00:01 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this Patch.
>> 
>> **Description:**
>> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update trimNativeHeap.cpp
>   
>   remove std::nothrow and rely on the default new handling

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27275#pullrequestreview-3228156713

From ayang at openjdk.org  Tue Sep 16 07:56:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 16 Sep 2025 07:56:50 GMT
Subject: RFR: 8367552: JCmdTestFileSafety.java fails when run by root user
 [v2]
In-Reply-To: <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
 <eJ5sxGj6_OIUa7-ctlP2lA-upsWpZfPXfnQlExKU1Vw=.cb627432-80e9-4919-8db0-9a2260830ee4@github.com>
Message-ID: <Wh5L0lgl-YxO36bPYWQun6K2eiC8oGKVYAGLJj-Ni0w=.bbffcdbc-7ad3-4111-bd2f-c4fc3dc04776@github.com>

On Mon, 15 Sep 2025 23:45:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
>> 
>> I propose to skip it if we detect that 'root' is running it, should be a trivial change.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27261#pullrequestreview-3228171489

From shade at openjdk.org  Tue Sep 16 07:57:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 Sep 2025 07:57:50 GMT
Subject: RFR: 8366229: runtime/Thread/TooSmallStackSize.java runs with all
 collectors
In-Reply-To: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>
References: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>
Message-ID: <E5AJJ8a3B9mnlNx2LP86xBQCukhW-nE1uHOyyWi841w=.f199fac3-684e-4d1d-a916-259eea52e625@github.com>

On Mon, 15 Sep 2025 15:39:16 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This change forces the `TooSmallStackSize.java` test to run on flagless VMs. Previously, this could get influenced by GC choice, whose flags were never propagated to the subprocess.
> 
> Testing: tier 1.
> 
> N.B.: Please ignore my fork's branch name, I copied and pasted the wrong ID.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27297#pullrequestreview-3228176450

From fandreuzzi at openjdk.org  Tue Sep 16 08:04:00 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 16 Sep 2025 08:04:00 GMT
Subject: Integrated: 8367552: JCmdTestFileSafety.java fails when run by root
 user
In-Reply-To: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
References: <hsrQW_B42eWUoPxOwrkXPNK-rXNRE7_eqxqEaSiG5bI=.ba55d21f-5215-4f20-a357-a1c081c0ec34@github.com>
Message-ID: <zvK0VtzjCLjfJ2z_F6hOAmuFYnv9FdU4003NpbmNUP8=.4d401198-19ff-40b5-ac0c-4699e35d8566@github.com>

On Fri, 12 Sep 2025 15:30:49 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I noticed this while running the test in a Docker container. The test tries to call `File.setWriteable(false)` on a directory in which it later tries to override an existing CDS archive. Since the root user is not affected by the missing write permission, the test fails consistently.
> 
> I propose to skip it if we detect that 'root' is running it, should be a trivial change.

This pull request has now been integrated.

Changeset: eb26865c
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb26865c36f1961ee802c8db812c786d4bdd4944
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8367552: JCmdTestFileSafety.java fails when run by root user

Reviewed-by: dcubed, ayang, phubner

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

PR: https://git.openjdk.org/jdk/pull/27261

From ghan at openjdk.org  Tue Sep 16 08:05:03 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 16 Sep 2025 08:05:03 GMT
Subject: RFR: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor [v2]
In-Reply-To: <DUowxMTwTyAfDo9tKaridInNVjd3U4MSUJffXoBkFbY=.dd6d597d-85ad-46f5-97da-d9cd46ecd9e3@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
 <3F17bXFBkKO3iW4jEtzoNwOG5vsNitz1ntjugvd9WBk=.2ccd4fd2-1898-4a4c-9ef1-e40fb0ab2560@github.com>
 <DUowxMTwTyAfDo9tKaridInNVjd3U4MSUJffXoBkFbY=.dd6d597d-85ad-46f5-97da-d9cd46ecd9e3@github.com>
Message-ID: <noCvd4AR4xIdqc9FlDqI7utHk4iw434pczrPIOdw94k=.6b1cea5b-4095-413e-8cf0-e644b276b1cf@github.com>

On Tue, 16 Sep 2025 07:51:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update trimNativeHeap.cpp
>>   
>>   remove std::nothrow and rely on the default new handling
>
> Marked as reviewed by ayang (Reviewer).

Hi @albertnetymk , thanks?

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

PR Comment: https://git.openjdk.org/jdk/pull/27275#issuecomment-3296424278

From ghan at openjdk.org  Tue Sep 16 08:05:04 2025
From: ghan at openjdk.org (Guanqiang Han)
Date: Tue, 16 Sep 2025 08:05:04 GMT
Subject: Integrated: 8366925: Improper std::nothrow new expression in
 NativeHeapTrimmerThread ctor
In-Reply-To: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
References: <WmTbm_r6HKDJzXQIzEj3WsDwlNUuHjNJ34xLKi9431U=.5ed86b48-938b-4447-aff8-acc2e92f0ed1@github.com>
Message-ID: <SfdgDb5JS9j7sLDWcO48lMyN0v9Zc48z3G4q_t2u0tE=.54a159ff-3982-4c50-a1f6-a6283234c489@github.com>

On Mon, 15 Sep 2025 01:01:17 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

> Please review this Patch.
> 
> **Description:**
> Add null check for _lock in NativeHeapTrimmerThread constructor. If allocation of the lock fails (_lock == nullptr), it indicates an out-of-memory condition. Since even this small allocation failed, it's unlikely that subsequent operations would succeed, so we terminate the JVM immediately.

This pull request has now been integrated.

Changeset: 3ba2e748
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ba2e748d61a9ed8098093c6d4732973051808b2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8366925: Improper std::nothrow new expression in NativeHeapTrimmerThread ctor

Reviewed-by: ayang, kbarrett, dholmes

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

PR: https://git.openjdk.org/jdk/pull/27275

From azafari at openjdk.org  Tue Sep 16 09:03:57 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 16 Sep 2025 09:03:57 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree [v2]
In-Reply-To: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
Message-ID: <88Ve4wkLTI5s2uzgk3x2Hnf4KZzGC68TP_Et1utmvrM=.62d00c09-98eb-43d3-8b08-d326a9690d47@github.com>

> `SummaryDiff` result of any `register_mapping()` call, is passed into the function rather than returned. This enables avoiding copying the structure to/from the stack.
> 
> Tests:
> local linux-x64-debug: NMT gtests and JTREGs passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  better naming for diff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26761/files
  - new: https://git.openjdk.org/jdk/pull/26761/files/e1c88ff2..9b53507d

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

  Stats: 89 lines in 2 files changed: 0 ins; 0 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/26761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26761/head:pull/26761

PR: https://git.openjdk.org/jdk/pull/26761

From azafari at openjdk.org  Tue Sep 16 09:04:01 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 16 Sep 2025 09:04:01 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree [v2]
In-Reply-To: <PzpjRcfIp2QswCXuxRlfuDWS1knmb5S9crC2E-NJ6I4=.fa605b23-0b83-4c47-a9a3-2dc9140ff276@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
 <PzpjRcfIp2QswCXuxRlfuDWS1knmb5S9crC2E-NJ6I4=.fa605b23-0b83-4c47-a9a3-2dc9140ff276@github.com>
Message-ID: <8Cz6ZelI2muMYx-9yxiCAlQuwXaLrDVc2e52AV2tgBI=.9efa2835-af45-4aab-8879-b82ec8152f40@github.com>

On Wed, 27 Aug 2025 12:47:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better naming for diff
>
> src/hotspot/share/nmt/vmatree.cpp line 248:
> 
>> 246:                                                const RegionData& metadata, VMATree::SummaryDiff& diff, bool use_tag_inplace) {
>> 247: 
>> 248:   diff.clear();
> 
> I'm not sure I follow why this is introduced. Is there a situation where we/it makes sense to re-use `SumaryDiff`s?

It's a bit backward support. The `diff` was constructed locally inside this method and thus was clean. All the callers of this method (mostly from tests) also assume so. Therefore, without this new explicit `clean()` all of them should have called the `clean()` themselves.

> test/hotspot/gtest/nmt/test_regions_tree.cpp line 102:
> 
>> 100:   NativeCallStack ncs;
>> 101:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
>> 102:   VMATree::SummaryDiff diff;
> 
> Nit: it's unused in the actual test/assertions right? Would call it `not_used` to be consistent with above test code then.

Good point. 
Done.

> test/hotspot/gtest/nmt/test_regions_tree.cpp line 121:
> 
>> 119:   NativeCallStack ncs;
>> 120:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
>> 121:   VMATree::SummaryDiff diff;
> 
> Same naming nit here.

Done.

> test/hotspot/gtest/nmt/test_regions_tree.cpp line 137:
> 
>> 135:   NativeCallStack ncs;
>> 136:   VMATree::RegionData rd = rt.make_region_data(ncs, mtTest);
>> 137:   VMATree::SummaryDiff diff;
> 
> Same naming nit here.

Done.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 1112:
> 
>> 1110:   {// Check committing into a reserved region inherits the call stacks
>> 1111:     Tree tree;
>> 1112:     VMATree::SummaryDiff diff;
> 
> Same nitpick here as in the other places in this file, I think it's more clear if we used `not_used` for cases where we discard the result. I'll stop pointing out every place this happens, consider this comment for the whole file.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2351572460
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2351573798
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2351574206
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2351574601
PR Review Comment: https://git.openjdk.org/jdk/pull/26761#discussion_r2351575139

From phubner at openjdk.org  Tue Sep 16 09:32:19 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:32:19 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree [v2]
In-Reply-To: <88Ve4wkLTI5s2uzgk3x2Hnf4KZzGC68TP_Et1utmvrM=.62d00c09-98eb-43d3-8b08-d326a9690d47@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
 <88Ve4wkLTI5s2uzgk3x2Hnf4KZzGC68TP_Et1utmvrM=.62d00c09-98eb-43d3-8b08-d326a9690d47@github.com>
Message-ID: <-dsE2GxVCXnYXtovE2OTIHvzluuP-EFg-M018hduq_c=.c5a2bfcf-4cd9-40ed-b8e7-ba00a067d429@github.com>

On Tue, 16 Sep 2025 09:03:57 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> `SummaryDiff` result of any `register_mapping()` call, is passed into the function rather than returned. This enables avoiding copying the structure to/from the stack.
>> 
>> Tests:
>> local linux-x64-debug: NMT gtests and JTREGs passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better naming for diff

Marked as reviewed by phubner (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/26761#pullrequestreview-3228689604

From phubner at openjdk.org  Tue Sep 16 09:35:02 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:35:02 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
Message-ID: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>

> Hi all,
> 
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
> 2) removes `FilteredJavaFieldStream` entirely, and
> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
> 
> Testing: Oracle tiers 1-3.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8365858
 - Merge branch 'master' into JDK-8365858
 - Fix typo.
 - Refactor to purely use injected fields.
 - Remove FilteredJavaFieldStream and usages.
 - Remove constantPoolOop from Java code.
 - Make constantPoolOop a hidden vmholder field.

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

Changes: https://git.openjdk.org/jdk/pull/27209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=01
  Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209

PR: https://git.openjdk.org/jdk/pull/27209

From phubner at openjdk.org  Tue Sep 16 09:35:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:35:03 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary
In-Reply-To: <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Bx6fwP7luYX6eCGcAvgjReYacki2TrQOrSSnXPnDg-k=.9cdea86d-febd-42a3-b9b9-93bd1597a2a4@github.com>
Message-ID: <vvepwKvbHE8VJFfW_lHJUP6YYem9qZCAW36oICqkbDA=.9f18101f-3801-418c-863a-b41e216c51ce@github.com>

On Mon, 15 Sep 2025 16:00:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find.

Thanks for the reviews, @coleenp @liach @jdksjolen @alexmenkov. I've merged in the latest mainline which had a merge commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3297070955

From azafari at openjdk.org  Tue Sep 16 09:36:22 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 16 Sep 2025 09:36:22 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v5]
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <P5YnGDYNq70P8cYBXo9JuQfWKcnkqSf3x9f6q1asWZM=.91ab7383-d351-465d-8687-117586f309a4@github.com>

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset
 - comment fixed
 - Merge remote-tracking branch 'origin/master' into _8366062_ubsan_nullptr_plus_nz_offset
 - comments improved
 - 8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

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

Changes: https://git.openjdk.org/jdk/pull/26983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26983&range=04
  Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26983/head:pull/26983

PR: https://git.openjdk.org/jdk/pull/26983

From jsjolen at openjdk.org  Tue Sep 16 12:21:17 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 16 Sep 2025 12:21:17 GMT
Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2]
In-Reply-To: <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
References: <xYBQO-N4UetYJq7AfONZnpWkTrmveB6igtXQZbO4OYc=.6aa64caf-c0a0-4d6f-9e99-6dc4c0fdb552@github.com>
 <Tb6kLmrfktZfyoQal7kgey-Cq_-a21FIrjNBMbcqQvw=.e87a4f3f-10a0-43d4-b8be-6b6bd22e3878@github.com>
Message-ID: <8fizZwH_W2n31RiJAJZAxU0dMFs3UaLU0Uk-yoTHST0=.7ab516ac-e506-4635-b08e-f4a3af4cfb7b@github.com>

On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR:
>> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases),
>> 2) removes `FilteredJavaFieldStream` entirely, and
>> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead.
>> 
>> Testing: Oracle tiers 1-3.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8365858
>  - Merge branch 'master' into JDK-8365858
>  - Fix typo.
>  - Refactor to purely use injected fields.
>  - Remove FilteredJavaFieldStream and usages.
>  - Remove constantPoolOop from Java code.
>  - Make constantPoolOop a hidden vmholder field.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3229698749