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

From liach at openjdk.org  Tue Sep 16 15:01:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Sep 2025 15:01:24 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: <u5krOkF_uMpGAxHbdLXKyP4Rz-9YK-qW65UCny5075c=.d7d49d04-3584-4cd3-8f74-430df39e9b31@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.

Still looks good

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3230428037

From phubner at openjdk.org  Tue Sep 16 16:19:13 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 16:19:13 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: <oxzS7rXgSjMCyoFHisjhdTO-6yYqorBTqkup3YvASk8=.9006018c-1421-4fc9-938c-75706a489de3@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.

Thanks for the reviews everyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299475347

From phubner at openjdk.org  Tue Sep 16 16:22:18 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 16:22:18 GMT
Subject: RFR: 8366229: runtime/Thread/TooSmallStackSize.java runs with all
 collectors
In-Reply-To: <7CTt5DcuXLK2v1lmyZJQfhOwnDoKNG45clxTrDCpSTI=.c0b96c06-0602-4a50-8854-e925f6d95044@github.com>
References: <occkqAahRcmGlJWR4ml3h1uYY__-peb2in7k8tfVdY8=.2fbf3bee-8555-40ff-a28a-1f290cb87f95@github.com>
 <7CTt5DcuXLK2v1lmyZJQfhOwnDoKNG45clxTrDCpSTI=.c0b96c06-0602-4a50-8854-e925f6d95044@github.com>
Message-ID: <wxJLCjsANKxebUSRp6MojtlKfyplnjfcvd7AO82WPFA=.8bcdf1bc-8399-4140-89dd-fc3fed3f7499@github.com>

On Tue, 16 Sep 2025 02:44:32 GMT, David Holmes <dholmes 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.
>
> PS. I consider this a trivial fix.

Thanks for the reviews @dholmes-ora @shipilev.

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

PR Comment: https://git.openjdk.org/jdk/pull/27297#issuecomment-3299478090

From duke at openjdk.org  Tue Sep 16 16:22:21 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 16:22:21 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: <BvnpINQyRGBopPH2LI7K_81HIBFKAHenFOvcc9NiTNg=.6aa539e6-c22c-4d92-ba88-0795058cef57@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.

@Arraying 
Your change (at version 54bc0476fe86c9b1759fff8c0062069ff3e536fa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299484854

From duke at openjdk.org  Tue Sep 16 16:22:21 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 16:22:21 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: <l_EDtN9XGOccFtHl0hMy2D9ivIrQ3rXdfH1znKxoQEg=.92559118-a398-41bc-a6a2-8b155ce4e7d3@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.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27297#issuecomment-3299485514

From phubner at openjdk.org  Tue Sep 16 16:55:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 16:55:59 GMT
Subject: Integrated: 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: <4sRbdi2Q2rv2nKjHJCp_h9q5_00xAyo7IpjYcLwMO6U=.2b3bdaec-b4f1-4a4f-a75a-a2c71cc496a6@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.

This pull request has now been integrated.

Changeset: 075ebb4e
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/075ebb4ee592c10879799a68ba79f782ee49b60d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8366229: runtime/Thread/TooSmallStackSize.java runs with all collectors

Reviewed-by: dholmes, shade

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

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

From phubner at openjdk.org  Tue Sep 16 19:20:57 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 19:20:57 GMT
Subject: Integrated: 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: <j-kF5o3qAIVasjK1rctp1y_GKjhUqbVvQpX2Sn2iw6E=.e02e5a9f-ea50-4ea2-80b9-9d9c2d3e37e1@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 pull request has now been integrated.

Changeset: b75e35cb
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b75e35cb94d17a742d88f23dfd1b016c26a5e63c
Stats:     194 lines in 9 files changed: 9 ins; 166 del; 19 mod

8365858: FilteredJavaFieldStream is unnecessary

Reviewed-by: liach, jsjolen, coleenp, amenkov

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

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

From iklam at openjdk.org  Tue Sep 16 20:51:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 16 Sep 2025 20:51:48 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
Message-ID: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>

Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).

We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.

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

Commit messages:
 - 8362657: Make tables used in AOT assembly phase GC-safe

Changes: https://git.openjdk.org/jdk/pull/27323/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27323&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362657
  Stats: 86 lines in 7 files changed: 62 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/27323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27323/head:pull/27323

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

From dholmes at openjdk.org  Wed Sep 17 01:17:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 01:17:43 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
Message-ID: <nSU5AKA4gXnNIiDBMsLOt1-UBZ1SVcXACqYaL-_OGKQ=.e3e83a0c-8534-4a98-8f1c-5fb17c6de143@github.com>

On Tue, 16 Sep 2025 20:42:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
> 
> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.

src/hotspot/share/cds/heapShared.cpp line 2130:

> 2128: // These tables should be used only within the CDS safepoint, so
> 2129: // delete them before we exit the safepoint. Otherwise the table will
> 2130: // contain bad oops after a GC.

So is this just for good code hygiene? I don't see any changes that involve checking these table pointers for null, so presumably no code actually tries to access them outside the safepoint?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27323#discussion_r2353973680

From dholmes at openjdk.org  Wed Sep 17 01:28:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 01:28:39 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v5]
In-Reply-To: <P5YnGDYNq70P8cYBXo9JuQfWKcnkqSf3x9f6q1asWZM=.91ab7383-d351-465d-8687-117586f309a4@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <P5YnGDYNq70P8cYBXo9JuQfWKcnkqSf3x9f6q1asWZM=.91ab7383-d351-465d-8687-117586f309a4@github.com>
Message-ID: <lkzvEhLnWj-zCN3HzT9FUmyJEs5atSPN4neC6Mmjo9s=.d78ccae4-fbef-4716-adb5-eec8813b3a2b@github.com>

On Tue, 16 Sep 2025 09:36:22 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 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

@afshin-zafari  it looks like you have mis-merged this and have kept the old MetaspaceShared names instead of the new AOTMetaspace ones.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3232165840

From iklam at openjdk.org  Wed Sep 17 05:04:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Sep 2025 05:04:33 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <nSU5AKA4gXnNIiDBMsLOt1-UBZ1SVcXACqYaL-_OGKQ=.e3e83a0c-8534-4a98-8f1c-5fb17c6de143@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
 <nSU5AKA4gXnNIiDBMsLOt1-UBZ1SVcXACqYaL-_OGKQ=.e3e83a0c-8534-4a98-8f1c-5fb17c6de143@github.com>
Message-ID: <VyuI9wpbAJ4f0iVYmANVXN6dZbloxzJoRq3Ti1FcZU8=.f84ed9fc-4d6e-41ea-9a5c-4471f75230ec@github.com>

On Wed, 17 Sep 2025 01:14:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
>> 
>> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.
>
> src/hotspot/share/cds/heapShared.cpp line 2130:
> 
>> 2128: // These tables should be used only within the CDS safepoint, so
>> 2129: // delete them before we exit the safepoint. Otherwise the table will
>> 2130: // contain bad oops after a GC.
> 
> So is this just for good code hygiene? I don't see any changes that involve checking these table pointers for null, so presumably no code actually tries to access them outside the safepoint?

Yes, this code is just for code hygiene for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27323#discussion_r2354304184

From kbarrett at openjdk.org  Wed Sep 17 05:56:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 17 Sep 2025 05:56:04 GMT
Subject: RFR: 8367796: Rename AtomicAccess gtests
Message-ID: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>

Please review this trivial renaming change. AtomicAccess gtest names and
supporting classes are being renamed to use "AtomicAccess" nomenclature,
rather than just "Atomic". (The potential for ODR violations could have been
eliminated by instead using anonymous namespaces, but use of those is still
not permitted in HotSpot.)

Testing: mach5 tier1

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

Commit messages:
 - rename AtomicAccess gtests

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

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

From ayang at openjdk.org  Wed Sep 17 08:41:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 08:41:54 GMT
Subject: RFR: 8367796: Rename AtomicAccess gtests
In-Reply-To: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
References: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
Message-ID: <I3wXtMLFhFDTBueHxbzdD-FXU-r7m7ey2q7CAQzd-VE=.69e2ecb8-594e-4bf3-ab8a-ef3387b580f9@github.com>

On Wed, 17 Sep 2025 05:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial renaming change. AtomicAccess gtest names and
> supporting classes are being renamed to use "AtomicAccess" nomenclature,
> rather than just "Atomic". (The potential for ODR violations could have been
> eliminated by instead using anonymous namespaces, but use of those is still
> not permitted in HotSpot.)
> 
> Testing: mach5 tier1

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27330#pullrequestreview-3233329825

From shade at openjdk.org  Wed Sep 17 09:52:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Sep 2025 09:52:50 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
Message-ID: <MqbyZ4aloYoi4GUQtt8qLxJEpw-0SMKxdXpPnDvc_Ug=.cffd63ee-9bac-4ca3-b91f-394c7a9dd898@github.com>

On Tue, 16 Sep 2025 20:42:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
> 
> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.

I remember reviewing this in Leyden/premain downstream. This looks good for mainline.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27323#pullrequestreview-3233601632

From azafari at openjdk.org  Wed Sep 17 09:53:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 17 Sep 2025 09:53:28 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v6]
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: <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@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:

  fix after wrong merge.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26983/files
  - new: https://git.openjdk.org/jdk/pull/26983/files/4ae49253..a2a4dec2

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

  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 duke at openjdk.org  Wed Sep 17 09:55:20 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 17 Sep 2025 09:55:20 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
Message-ID: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>

Hi, please consider the following changes:

In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 

The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 

Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.

Tested in tiers 1 - 3.

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

Commit messages:
 - 8367485: Whitespace fix.
 - 8367485: Fixed overflow issue in os::physical_memory on Linux.

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

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

From aph at openjdk.org  Wed Sep 17 09:55:24 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Sep 2025 09:55:24 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <BDeVXupWhCZKesuxBL0WQrlY8GXJQ7ANlEDIDh6Qg4E=.97cfcb41-ad9d-45c5-89d8-7052013266b5@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

Wouldn't it be better effectively to restore the status quo ante, albeit with a standard type such as `uint64_t`?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3301991245

From duke at openjdk.org  Wed Sep 17 09:55:27 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 17 Sep 2025 09:55:27 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <BDeVXupWhCZKesuxBL0WQrlY8GXJQ7ANlEDIDh6Qg4E=.97cfcb41-ad9d-45c5-89d8-7052013266b5@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <BDeVXupWhCZKesuxBL0WQrlY8GXJQ7ANlEDIDh6Qg4E=.97cfcb41-ad9d-45c5-89d8-7052013266b5@github.com>
Message-ID: <ai8NYgMTfUx9gToGXmIj85WqTDwJLosEgt-MQF2JKN0=.be8f0426-6ce1-48c4-b4cd-ce5570a9752f@github.com>

On Wed, 17 Sep 2025 08:50:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Wouldn't it be better effectively to restore the status quo ante, albeit with a standard type such as `uint64_t`?

Do you think that all memory functions should return `uint64_t` then, not only `physical_memory()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3302016434

From shade at openjdk.org  Wed Sep 17 10:13:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Sep 2025 10:13:10 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <dtFnJHla5syVp0RYHFO9-OH0hTICwgvYZ5b-SnQz5lo=.d9ce9b79-e48b-4fbb-852e-75dc035efee1@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

So it looks like JDK-8357086 made the assumption that `size_t` is enough to represent system memory sizes on 32-bit systems. Which is demonstrably not true, since 32-bit PAE systems are a thing :) Yes, if we don't want to go back to `julong`, memory sizes should be in `uint64_t`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3302277040

From duke at openjdk.org  Wed Sep 17 10:18:02 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 17 Sep 2025 10:18:02 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <zytJ91JQaSbPdyYvHQeSShaVedJy1-kuAHnQNuv1uzw=.67783aa3-7e7a-4c4f-8326-879fb335ed00@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

@stefank any thoughts on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3302307688

From aph at openjdk.org  Wed Sep 17 10:18:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Sep 2025 10:18:00 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <ai8NYgMTfUx9gToGXmIj85WqTDwJLosEgt-MQF2JKN0=.be8f0426-6ce1-48c4-b4cd-ce5570a9752f@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <BDeVXupWhCZKesuxBL0WQrlY8GXJQ7ANlEDIDh6Qg4E=.97cfcb41-ad9d-45c5-89d8-7052013266b5@github.com>
 <ai8NYgMTfUx9gToGXmIj85WqTDwJLosEgt-MQF2JKN0=.be8f0426-6ce1-48c4-b4cd-ce5570a9752f@github.com>
Message-ID: <7jpSkRWEmZ5scvqfrmmT2kfj6XtbaEri3MMRD89eN_Q=.c1f6ca85-7393-469b-97ab-52ce81ed282c@github.com>

On Wed, 17 Sep 2025 08:58:05 GMT, Anton Artemov <duke at openjdk.org> wrote:

> > Wouldn't it be better effectively to restore the status quo ante, albeit with a standard type such as `uint64_t`?
> 
> Do you think that all memory functions should return `uint64_t` then, not only `physical_memory()`?

Yes. `available_memory()` should report the available memory reported by the OS.

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3302301313

From ayang at openjdk.org  Wed Sep 17 10:37:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 10:37:06 GMT
Subject: RFR: 8367860: Remove unused NMethodToOopClosure::fix_relocations
Message-ID: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>

Trivial removing dead code.

Test: tier1

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

Commit messages:
 - trivial-remove

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

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

From fandreuzzi at openjdk.org  Wed Sep 17 11:54:53 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 17 Sep 2025 11:54:53 GMT
Subject: RFR: 8367860: Remove unused NMethodToOopClosure::fix_relocations
In-Reply-To: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
References: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
Message-ID: <Aqfjrs-S3aoviGfUaSSpJmiewC9o5jLT3Gk4cf-zNPo=.cfad002b-008d-4ca9-a5b9-74cf0b04deed@github.com>

On Wed, 17 Sep 2025 10:28:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27339#pullrequestreview-3234063818

From ayang at openjdk.org  Wed Sep 17 13:01:29 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 13:01:29 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <tUujbYahWzDkOCtqv3P22OkM30BabUuH38DjqKCfqLM=.5f208643-c7ca-4523-9380-4c907ad72802@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

src/hotspot/os/linux/os_linux.cpp line 545:

> 543:   }
> 544:   const long int n_phys_pages = sysconf(_SC_PHYS_PAGES);
> 545:   const long int page_size = sysconf(_SC_PAGESIZE);

How about just `long`, instead of `long int`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2355440432

From tschatzl at openjdk.org  Wed Sep 17 13:29:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 17 Sep 2025 13:29:24 GMT
Subject: RFR: 8367796: Rename AtomicAccess gtests
In-Reply-To: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
References: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
Message-ID: <Zt0LzWXH5f9zGnTQ86PCW7aGycPW3dNQuDxOE8vbfx4=.24af4389-723a-449d-b263-534ff17e23d4@github.com>

On Wed, 17 Sep 2025 05:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial renaming change. AtomicAccess gtest names and
> supporting classes are being renamed to use "AtomicAccess" nomenclature,
> rather than just "Atomic". (The potential for ODR violations could have been
> eliminated by instead using anonymous namespaces, but use of those is still
> not permitted in HotSpot.)
> 
> Testing: mach5 tier1

Marked as reviewed by tschatzl (Reviewer).

I think this is trivial enough.

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

PR Review: https://git.openjdk.org/jdk/pull/27330#pullrequestreview-3234468181
PR Comment: https://git.openjdk.org/jdk/pull/27330#issuecomment-3303014035

From tschatzl at openjdk.org  Wed Sep 17 13:33:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 17 Sep 2025 13:33:43 GMT
Subject: RFR: 8367860: Remove unused NMethodToOopClosure::fix_relocations
In-Reply-To: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
References: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
Message-ID: <LfBGzMmarTwLyp7FVET_euSCJqE6VeRGvoBor3sd7Mo=.01cac8cf-274c-4c3a-b0ef-7cee3acad111@github.com>

On Wed, 17 Sep 2025 10:28:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27339#pullrequestreview-3234485483

From stuefe at openjdk.org  Wed Sep 17 13:44:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 Sep 2025 13:44:35 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <JV1-wXrUfy2a0iduJt-yp_0AcprjvIEnG7qYFgIC5j4=.36301acf-81e0-45fe-886b-5d3d8a5e8a66@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

Do we really want to do this? This feels like regressing. 32-bit is on the way out.

Why not just cap the returned value to SIZE_MAX/4G in this case, since for all practical matters the JVM will not be able to handle more memory? Or do we use LPAE anywhere? Why cater to such an odd corner case?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3303070087

From shade at openjdk.org  Wed Sep 17 13:53:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Sep 2025 13:53:20 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <JV1-wXrUfy2a0iduJt-yp_0AcprjvIEnG7qYFgIC5j4=.36301acf-81e0-45fe-886b-5d3d8a5e8a66@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <JV1-wXrUfy2a0iduJt-yp_0AcprjvIEnG7qYFgIC5j4=.36301acf-81e0-45fe-886b-5d3d8a5e8a66@github.com>
Message-ID: <71UEi9xvXyE7e_U64h5XzsMliRH-cLK3OZ1tnaS06lE=.db0b0159-366c-4124-a586-150cbb737be3@github.com>

On Wed, 17 Sep 2025 13:41:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Do we really want to do this? This feels like regressing. 32-bit is on the way out.

Conceptually, the machine data model width (`size_t`) does not put a limit on system memory size. So, switching from `julong` to `size_t` in JDK-8357086 _is_ the regression from that concept. `size_t` is simply a too narrow type to use here, even if it happens to work on 64-bits. We can assume that 64-bit would be enough to cover all machines, so `uint64_t` would work.

> Why not just cap the returned value to SIZE_MAX/4G in this case, since for all practical matters the JVM will not be able to handle more memory? 

AFAICS, this data is fed to various management beans reporting the system memory size, so capping at 4G contradicts their intended behavior, if not their spec?

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3303106256

From ayang at openjdk.org  Wed Sep 17 13:58:24 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 13:58:24 GMT
Subject: RFR: 8367860: Remove unused NMethodToOopClosure::fix_relocations
In-Reply-To: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
References: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
Message-ID: <hp-F2TT1xa_sAi5P13v1p_vjkurwiiwoGzYmrJcPYsM=.21fc5c38-cace-4d66-a7a2-2e89deedf366@github.com>

On Wed, 17 Sep 2025 10:28:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27339#issuecomment-3303124546

From ayang at openjdk.org  Wed Sep 17 14:01:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 14:01:04 GMT
Subject: Integrated: 8367860: Remove unused
 NMethodToOopClosure::fix_relocations
In-Reply-To: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
References: <26UHziycGvBQai46k0j5JJu1Hj6hJq6VSPd9nWPXAB4=.a23118e2-70a4-4239-93dc-c2ac162d4ed2@github.com>
Message-ID: <lK4r-2RlNI3BitvWx5gOnrRMnopRmGFyKtJus6Irab4=.aa30e849-b4a4-46b2-b0a6-258de3914e44@github.com>

On Wed, 17 Sep 2025 10:28:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 91afdaff
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91afdaff80459ec8ffff859f29fdadf1c631fddb
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8367860: Remove unused NMethodToOopClosure::fix_relocations

Reviewed-by: fandreuzzi, tschatzl

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

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

From tschatzl at openjdk.org  Wed Sep 17 14:03:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 17 Sep 2025 14:03:58 GMT
Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask
Message-ID: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com>

Hi all,

  please review this change to parallel klass cleaning to improve performance.

The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads.

Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads).

The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass.

E.g.

CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4;
vertical links are subklass references, while horizontal links are sibling references.

j.l.O
  |
  A - B - c - 3
  |
  0 - 2 - C - 1


CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead).

So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`.
Thread 2 will only remove the link to `3` of `c`.

The result is

j.l.O
  |
  A - B - c
  |
  C


There should be no unnecessary object graph walking.

There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print


unlinking class (subclass): 0
unlinking class (subclass): 2


With the change, to avoid following the subklasses of the graph twice, it prints


?unlinking class (subclass): 0
unlinking class (sibling): 0


because the string in brackets is the actual link that is followed. I can revert that change.

With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading).

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - * cleanup
 - * improve clean_subklass() to return the last live Klass to avoid the repeating the walk
 - Merge branch 'master' into 8363932-klasstaskcleaning-distribution
 - * somewhat fixed logging
 - * cleanup
 - * fix includes
 - * some more changes, works now?
 - * some attempts to improve class unloading

Changes: https://git.openjdk.org/jdk/pull/27316/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27316&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363932
  Stats: 116 lines in 7 files changed: 6 ins; 61 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27316.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27316/head:pull/27316

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

From stefank at openjdk.org  Wed Sep 17 14:56:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Sep 2025 14:56:31 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <w4z53bDVWR3IAIwCbw8brLW1Mqme8wQon1tMSgniKTk=.2d5f831f-5095-46a0-a351-052511d7fb5e@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by checking if the product (represented as `uint64_t`) exceeds the maximum value representable by `size_t`, and, if so `std::numeric_limits<size_t>::max()` is returned as physical memory. If there is no overflow detected, the product of _SC_PHYS_PAGES  and _SC_PAGESIZE  is returned. 
> 
> Note that this change does not roll back to the old behavior (pre https://bugs.openjdk.org/browse/JDK-8357086). We keep consistency among memory functions return types.
> 
> Tested in tiers 1 - 3.

I really would have preferred if we could have used size_t for these, but as long as we are keeping 32-bit JVMs on life support I think we need to change this to use uint64_t.

I also considered the same approach that Anton proposes here, but I think it breaks code like this:

bool os::used_memory(size_t& value) {
...
  size_t avail_mem = 0;
  // Return value ignored - defaulting to 0 on failure.
  (void)os::available_memory(avail_mem);
  size_t phys_mem = os::physical_memory();
  value = phys_mem - avail_mem;
  return true;
}

The `os::available_memory` function needs to work the same way as `os::physical_memory` and if if both cap at 4 GB we will end up returning the wrong amount of used memory. We'll probably even return 0 used memory if the machine has a lot of memory.

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3303396533

From stefank at openjdk.org  Wed Sep 17 15:10:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Sep 2025 15:10:33 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v2]
In-Reply-To: <Rqr94I2WzG4Stv8RuYH1ArQDDEbBZ58d0tANPyuPklM=.2024270d-a879-4d8f-bc58-b6a79a216561@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <Rqr94I2WzG4Stv8RuYH1ArQDDEbBZ58d0tANPyuPklM=.2024270d-a879-4d8f-bc58-b6a79a216561@github.com>
Message-ID: <jAj-_68lPWc5563xep8dOn1Ul-uFLpd9pZtke1mUsWw=.c27da6cf-1b03-42fe-aac6-2344a563fa21@github.com>

On Wed, 17 Sep 2025 14:54:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Adding runtime because this now also touches the Threads class.

src/hotspot/share/gc/parallel/psScavenge.cpp line 237:

> 235: 
> 236: class ScavengeRootsTask : public WorkerTask {
> 237:   Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do

I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice?

Threads::ThreadsClaimTokenScope

vs

Threads::ClaimTokenScope

OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this.

src/hotspot/share/runtime/threads.hpp line 112:

> 110:       Threads::assert_all_threads_claimed();
> 111:     }
> 112:   };

I wonder if the implementation should be moved to the cpp file or if we consider this small enough to include here?

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

PR Comment: https://git.openjdk.org/jdk/pull/27336#issuecomment-3303451470
PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355850180
PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355850649

From sjohanss at openjdk.org  Wed Sep 17 15:13:46 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 17 Sep 2025 15:13:46 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: <HrLcTB-gWEdnID7qGySXXe-wbXeZVtC3TrC17oYTz_I=.5ae6ba5f-339f-4e52-875f-ee096d00056e@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

Looking for a second reviewer. @tstuefe do you have time to take a closer look.

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3303467197

From stefank at openjdk.org  Wed Sep 17 15:20:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Sep 2025 15:20:25 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: <Ykgk7hEmIQw9ynw090K8Q4PY9KfUyoTlqltRlDE_y4U=.337ccab0-b75f-43e3-ac1c-c193c1948021@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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27245#issuecomment-3303484410

From stefank at openjdk.org  Wed Sep 17 15:20:29 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Sep 2025 15:20:29 GMT
Subject: Integrated: 8367486: Change prefix for platform-dependent AtomicAccess
 files
In-Reply-To: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
References: <ntzrtWV0WzV3JCsLy7RZr5OIUwr5lzJ_sx0sKeLHFQU=.535e12bc-2d8a-4f8d-b63f-7260b37a06e2@github.com>
Message-ID: <Qpw4d2qZy27js-aWnUsXbe6sMR01xHDxzvkL_RERuJI=.0054b398-4572-4d3b-a6c9-273e28684cb7@github.com>

On Fri, 12 Sep 2025 07:28:10 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.

This pull request has now been integrated.

Changeset: 01d7554b
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01d7554b87fb7be8cab5dc12fd67eaba6585d2f3
Stats:     55 lines in 16 files changed: 2 ins; 3 del; 50 mod

8367486: Change prefix for platform-dependent AtomicAccess files

Reviewed-by: kbarrett, ayang

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

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

From ayang at openjdk.org  Wed Sep 17 15:54:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 15:54:45 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v2]
In-Reply-To: <jAj-_68lPWc5563xep8dOn1Ul-uFLpd9pZtke1mUsWw=.c27da6cf-1b03-42fe-aac6-2344a563fa21@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <Rqr94I2WzG4Stv8RuYH1ArQDDEbBZ58d0tANPyuPklM=.2024270d-a879-4d8f-bc58-b6a79a216561@github.com>
 <jAj-_68lPWc5563xep8dOn1Ul-uFLpd9pZtke1mUsWw=.c27da6cf-1b03-42fe-aac6-2344a563fa21@github.com>
Message-ID: <IT0dsovYnQDfia9ocPcbM-Nj_pRuDjfD5t8CzuYZEGk=.05b66a4e-4817-4fe2-a41c-2dba3e714e38@github.com>

On Wed, 17 Sep 2025 15:05:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/parallel/psScavenge.cpp line 237:
> 
>> 235: 
>> 236: class ScavengeRootsTask : public WorkerTask {
>> 237:   Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do
> 
> I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice?
> 
> Threads::ThreadsClaimTokenScope
> 
> vs
> 
> Threads::ClaimTokenScope
> 
> OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this.

`ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2355992008

From stefank at openjdk.org  Wed Sep 17 19:32:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Sep 2025 19:32:20 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v2]
In-Reply-To: <IT0dsovYnQDfia9ocPcbM-Nj_pRuDjfD5t8CzuYZEGk=.05b66a4e-4817-4fe2-a41c-2dba3e714e38@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <Rqr94I2WzG4Stv8RuYH1ArQDDEbBZ58d0tANPyuPklM=.2024270d-a879-4d8f-bc58-b6a79a216561@github.com>
 <jAj-_68lPWc5563xep8dOn1Ul-uFLpd9pZtke1mUsWw=.c27da6cf-1b03-42fe-aac6-2344a563fa21@github.com>
 <IT0dsovYnQDfia9ocPcbM-Nj_pRuDjfD5t8CzuYZEGk=.05b66a4e-4817-4fe2-a41c-2dba3e714e38@github.com>
Message-ID: <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com>

On Wed, 17 Sep 2025 15:51:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psScavenge.cpp line 237:
>> 
>>> 235: 
>>> 236: class ScavengeRootsTask : public WorkerTask {
>>> 237:   Threads::ThreadsClaimTokenScope _threads_claim_token_scope; // needed for Threads::possibly_parallel_threads_do
>> 
>> I wonder if this class could just be named ClaimTokenScope so that we don't need to see the word Threads twice?
>> 
>> Threads::ThreadsClaimTokenScope
>> 
>> vs
>> 
>> Threads::ClaimTokenScope
>> 
>> OTOH, the function is named `change_thread_claim_token`. Maybe the second reviewer could weigh in on this.
>
> `ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`.

Well, Threads::change_thread_claim_token() are also only used by GC but it is still located in Threads. Another alternative could be to put ThreadsClaimTokenScope at the end of threads.hpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2356545085

From kbarrett at openjdk.org  Wed Sep 17 20:24:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 17 Sep 2025 20:24:07 GMT
Subject: RFR: 8367796: Rename AtomicAccess gtests
In-Reply-To: <I3wXtMLFhFDTBueHxbzdD-FXU-r7m7ey2q7CAQzd-VE=.69e2ecb8-594e-4bf3-ab8a-ef3387b580f9@github.com>
References: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
 <I3wXtMLFhFDTBueHxbzdD-FXU-r7m7ey2q7CAQzd-VE=.69e2ecb8-594e-4bf3-ab8a-ef3387b580f9@github.com>
Message-ID: <kqptX2x-2JcnPD2ulNEdApDjF6iIY0qosqVtYSblaFY=.b1028a50-f579-4c60-b61b-3589d3af942b@github.com>

On Wed, 17 Sep 2025 08:38:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this trivial renaming change. AtomicAccess gtest names and
>> supporting classes are being renamed to use "AtomicAccess" nomenclature,
>> rather than just "Atomic". (The potential for ODR violations could have been
>> eliminated by instead using anonymous namespaces, but use of those is still
>> not permitted in HotSpot.)
>> 
>> Testing: mach5 tier1
>
> Marked as reviewed by ayang (Reviewer).

Thanks for reviews @albertnetymk and @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/27330#issuecomment-3304444622

From kbarrett at openjdk.org  Wed Sep 17 20:24:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 17 Sep 2025 20:24:08 GMT
Subject: Integrated: 8367796: Rename AtomicAccess gtests
In-Reply-To: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
References: <UdFp3OJYdHrwiKD67AJ2yt4eVCOTiou6H191evpo7Xc=.d25a57fd-d832-48dd-a5c8-17a081d3e233@github.com>
Message-ID: <g5ZyRqt0ZbmDm9Ia4A15ZeeEyW4xNLN5dlX-97HNBEs=.59a4a309-3c06-4717-9db8-0e5443e7314d@github.com>

On Wed, 17 Sep 2025 05:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial renaming change. AtomicAccess gtest names and
> supporting classes are being renamed to use "AtomicAccess" nomenclature,
> rather than just "Atomic". (The potential for ODR violations could have been
> eliminated by instead using anonymous namespaces, but use of those is still
> not permitted in HotSpot.)
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: f682f070
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f682f070079037f8fb646e91ea336af0bc778813
Stats:     52 lines in 1 file changed: 1 ins; 0 del; 51 mod

8367796: Rename AtomicAccess gtests

Reviewed-by: ayang, tschatzl

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

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

From dholmes at openjdk.org  Wed Sep 17 20:48:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 20:48:14 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v6]
In-Reply-To: <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@github.com>
Message-ID: <v6vXWchCvUYlr3b7Nh-WKuPge6iZl4YMj2jjiD7q1Pw=.2a226c97-61d0-45b7-833b-1f99bd548d0e@github.com>

On Wed, 17 Sep 2025 09:53:28 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:
> 
>   fix after wrong merge.

Looks okay again.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26983#pullrequestreview-3236221633

From dholmes at openjdk.org  Thu Sep 18 02:08:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 02:08:38 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v6]
In-Reply-To: <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@github.com>
Message-ID: <9ZXD5zmrOPt83KvfWAKRSGJgA5ZEujTsjquyT57wSws=.ba867127-ccd4-4ecc-aed3-5fa885192efb@github.com>

On Wed, 17 Sep 2025 09:53:28 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:
> 
>   fix after wrong merge.

BTW as per your related PR there could be some debate about the type used for the cast that then leads to questions about the types used by the other variables in the calculations. I decided not to open that can-of-worms here, but if a decision is made in that other PR then you may want to apply the same here.

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

PR Comment: https://git.openjdk.org/jdk/pull/26983#issuecomment-3305129639

From dholmes at openjdk.org  Thu Sep 18 06:26:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 06:26:35 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
Message-ID: <66FhoFhfDmAy92we7-bElv0Ux8k0ET31BB2yVL62y-o=.9b9fcc91-d8e1-477d-af88-c958684f605e@github.com>

On Tue, 16 Sep 2025 20:42:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
> 
> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.

Okay this seems reasonable.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27323#pullrequestreview-3237453975

From azafari at openjdk.org  Thu Sep 18 06:52:37 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 18 Sep 2025 06:52:37 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v5]
In-Reply-To: <lkzvEhLnWj-zCN3HzT9FUmyJEs5atSPN4neC6Mmjo9s=.d78ccae4-fbef-4716-adb5-eec8813b3a2b@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <P5YnGDYNq70P8cYBXo9JuQfWKcnkqSf3x9f6q1asWZM=.91ab7383-d351-465d-8687-117586f309a4@github.com>
 <lkzvEhLnWj-zCN3HzT9FUmyJEs5atSPN4neC6Mmjo9s=.d78ccae4-fbef-4716-adb5-eec8813b3a2b@github.com>
Message-ID: <XVvRTy2kWanvmzVZQE0vSY6meya6ogLmtMMuh22j5Lg=.c63eaf6f-57c4-4312-ad25-c013ba584052@github.com>

On Wed, 17 Sep 2025 01:26:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @afshin-zafari it looks like you have mis-merged this and have kept the old MetaspaceShared names instead of the new AOTMetaspace ones.

Thanks for noting this. Now it is fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26983#issuecomment-3305662727

From eosterlund at openjdk.org  Thu Sep 18 09:03:06 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 18 Sep 2025 09:03:06 GMT
Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
Message-ID: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>

On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory).
> 
> I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour.
> 
> Testing:
> - [x] GHA - tier 1 (windows failures seem infra related)
> - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests.
> 
> Thoughts? Opinions?

The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer. 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want. But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB. 

I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about *why* a limit is too high or too low, and adapting accordingly at runtime.

When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3306363643

From ayang at openjdk.org  Thu Sep 18 09:04:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 18 Sep 2025 09:04:27 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v3]
In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
Message-ID: <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>

> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>  
> Test: tier1-3

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27336/files
  - new: https://git.openjdk.org/jdk/pull/27336/files/69767adf..1f2e3a6b

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

  Stats: 20 lines in 2 files changed: 10 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27336/head:pull/27336

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

From ayang at openjdk.org  Thu Sep 18 09:04:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 18 Sep 2025 09:04:28 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v2]
In-Reply-To: <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <Rqr94I2WzG4Stv8RuYH1ArQDDEbBZ58d0tANPyuPklM=.2024270d-a879-4d8f-bc58-b6a79a216561@github.com>
 <jAj-_68lPWc5563xep8dOn1Ul-uFLpd9pZtke1mUsWw=.c27da6cf-1b03-42fe-aac6-2344a563fa21@github.com>
 <IT0dsovYnQDfia9ocPcbM-Nj_pRuDjfD5t8CzuYZEGk=.05b66a4e-4817-4fe2-a41c-2dba3e714e38@github.com>
 <0a04SdKiikKdYExWYiGfKjB2QtCOC0JLNw31DAVIiNU=.9310e70f-024b-4c43-95e6-bd2672ab0d65@github.com>
Message-ID: <MvgQm6thYo3uCC-P_tt91EFnj865gw-Fj4xGAgXZrUU=.81b57e11-6baa-4394-b0a3-c8b24a01849b@github.com>

On Wed, 17 Sep 2025 19:29:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> `ThreadsClaimTokenScope` should only be used by GC code, so I can put it in GC-shared code instead of `threads`.
>
> Well, Threads::change_thread_claim_token() are also only used by GC but it is still located in Threads. Another alternative could be to put ThreadsClaimTokenScope at the end of threads.hpp.

Moved to the end of `threads.hpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27336#discussion_r2358140692

From jsjolen at openjdk.org  Thu Sep 18 09:55:02 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 18 Sep 2025 09:55:02 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: <4QMdmn4CFbutMqIe78YdUQGBj3rLVyyXEkt5Ajf1B0k=.516427fd-4475-49dd-be22-ab17977d10ac@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.

OK, thanks

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27246#pullrequestreview-3238518243

From mli at openjdk.org  Thu Sep 18 11:00:36 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 18 Sep 2025 11:00:36 GMT
Subject: RFR: 8367981: Refine CompactHashtable comments
Message-ID: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>

Hi,
Can you help to review this patch?

The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
As the related classes are used in more and more scenarios, it's helpful to update the comments.

Thanks

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

Commit messages:
 - intial commit
 - Merge branch 'openjdk:master' into master
 - initial commit

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

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

From fandreuzzi at openjdk.org  Thu Sep 18 11:19:50 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 18 Sep 2025 11:19:50 GMT
Subject: RFR: 8367981: Refine CompactHashtable comments
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <3r0BpegTaqWjNoQvWsMJPqppPFmjlsx4x8XiigBk5as=.394cf3e5-55b4-4fe7-8f8e-981d77b929df@github.com>

On Thu, 18 Sep 2025 10:53:25 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> Thanks

src/hotspot/share/classfile/compactHashtable.cpp line 195:

> 193: size_t SimpleCompactHashtable::calculate_header_size() {
> 194:   // We have 5 fields. Each takes up sizeof(intptr_t). See WriteClosure::do_u4
> 195:   constexpr size_t bytes = sizeof(intptr_t) * 5;

The whole method could perhaps become a `constexpr`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2358666947

From fandreuzzi at openjdk.org  Thu Sep 18 11:23:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 18 Sep 2025 11:23:40 GMT
Subject: RFR: 8367981: Refine CompactHashtable comments
In-Reply-To: <3r0BpegTaqWjNoQvWsMJPqppPFmjlsx4x8XiigBk5as=.394cf3e5-55b4-4fe7-8f8e-981d77b929df@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <3r0BpegTaqWjNoQvWsMJPqppPFmjlsx4x8XiigBk5as=.394cf3e5-55b4-4fe7-8f8e-981d77b929df@github.com>
Message-ID: <spSo6CcBkLzsH4e4OH6aXYQpWz-6CvoDJFPU5qi2t7g=.e9c85ea3-4510-4397-a27e-f25491cf180e@github.com>

On Thu, 18 Sep 2025 11:17:25 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> Thanks
>
> src/hotspot/share/classfile/compactHashtable.cpp line 195:
> 
>> 193: size_t SimpleCompactHashtable::calculate_header_size() {
>> 194:   // We have 5 fields. Each takes up sizeof(intptr_t). See WriteClosure::do_u4
>> 195:   constexpr size_t bytes = sizeof(intptr_t) * 5;
> 
> The whole method could perhaps become a `constexpr`

And you could have the assertion below just after the class is defined

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2358687022

From mli at openjdk.org  Thu Sep 18 12:48:02 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 18 Sep 2025 12:48:02 GMT
Subject: RFR: 8367981: Refine CompactHashtable comments [v2]
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  remove calculate_header_size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27360/files
  - new: https://git.openjdk.org/jdk/pull/27360/files/9007c382..176fdc67

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

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

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

From mli at openjdk.org  Thu Sep 18 12:48:04 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 18 Sep 2025 12:48:04 GMT
Subject: RFR: 8367981: Refine CompactHashtable comments [v2]
In-Reply-To: <spSo6CcBkLzsH4e4OH6aXYQpWz-6CvoDJFPU5qi2t7g=.e9c85ea3-4510-4397-a27e-f25491cf180e@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <3r0BpegTaqWjNoQvWsMJPqppPFmjlsx4x8XiigBk5as=.394cf3e5-55b4-4fe7-8f8e-981d77b929df@github.com>
 <spSo6CcBkLzsH4e4OH6aXYQpWz-6CvoDJFPU5qi2t7g=.e9c85ea3-4510-4397-a27e-f25491cf180e@github.com>
Message-ID: <7erdeHX_R10n9KLlDK0fhQXFz_wK5n6-nL-zH667n6A=.c5ad99ca-d52a-42a7-9485-2e4bdf77592a@github.com>

On Thu, 18 Sep 2025 11:21:23 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> src/hotspot/share/classfile/compactHashtable.cpp line 195:
>> 
>>> 193: size_t SimpleCompactHashtable::calculate_header_size() {
>>> 194:   // We have 5 fields. Each takes up sizeof(intptr_t). See WriteClosure::do_u4
>>> 195:   constexpr size_t bytes = sizeof(intptr_t) * 5;
>> 
>> The whole method could perhaps become a `constexpr`
>
> And you could have the assertion below just after the class is defined

This can just be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2359064830

From duke at openjdk.org  Thu Sep 18 12:51:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 12:51:39 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v2]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <OJY7K_8iqHsncWPwlbkEquMjWcrJg1BSK-A3wzCrOT8=.ac1f1c4c-3ab0-431e-b45e-47d7fd4b9c3f@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Refactoring with uint64_t

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/8effef43..8e91019c

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

  Stats: 121 lines in 19 files changed: 0 ins; 7 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/27335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335

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

From duke at openjdk.org  Thu Sep 18 12:51:42 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 12:51:42 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <sdpOwehaBWUI0SCRr8syi4A_NHVV3iopItcWb_8jPKQ=.cf306409-61df-4ec3-bcc5-53f1054c5196@github.com>

On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

Thanks, I have re-factored everything with `uint64_t`. Now overflowing is not an issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3307269856

From fandreuzzi at openjdk.org  Thu Sep 18 12:53:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 18 Sep 2025 12:53:28 GMT
Subject: RFR: 8367984: Eliminate offset_of in vmStructs
Message-ID: <gMl5FcF4pRnK2Rqzwu-9SiHgqGXQpCPm-Sd9dQO35m4=.2217b178-8e68-4352-806f-f13950078d2f@github.com>

There are several usages of `offset_of` in `vmStructs`, they can be replaced with standard `offsetof` due to [JDK-8367016](https://bugs.openjdk.org/browse/JDK-8367016).

Passes `tier1`.

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

Commit messages:
 - stuff

Changes: https://git.openjdk.org/jdk/pull/27362/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27362&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367984
  Stats: 20 lines in 2 files changed: 2 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/27362.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27362/head:pull/27362

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

From fandreuzzi at openjdk.org  Thu Sep 18 12:53:29 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 18 Sep 2025 12:53:29 GMT
Subject: RFR: 8367984: Eliminate offset_of in vmStructs
In-Reply-To: <gMl5FcF4pRnK2Rqzwu-9SiHgqGXQpCPm-Sd9dQO35m4=.2217b178-8e68-4352-806f-f13950078d2f@github.com>
References: <gMl5FcF4pRnK2Rqzwu-9SiHgqGXQpCPm-Sd9dQO35m4=.2217b178-8e68-4352-806f-f13950078d2f@github.com>
Message-ID: <__SmTPxscRXLzen7lQ8ZE7nQOvcGfXGSE51UK41hHfI=.c3e35b17-d7ce-4c64-b70c-df37511a322e@github.com>

On Thu, 18 Sep 2025 12:44:27 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> There are several usages of `offset_of` in `vmStructs`, they can be replaced with standard `offsetof` due to [JDK-8367016](https://bugs.openjdk.org/browse/JDK-8367016).
> 
> Passes `tier1`.

src/hotspot/share/runtime/vmStructs.cpp line 1984:

> 1982: 
> 1983: JNIEXPORT VMStructEntry* gHotSpotVMStructs = VMStructs::localHotSpotVMStructs;
> 1984: extern JNIEXPORT constexpr uint64_t gHotSpotVMStructEntryTypeNameOffset = offsetof(VMStructEntry, typeName);

I got a partial understanding about this change, I thought having `JNIEXPORT` and `constexpr` together wouldn't work. But the symbols are exported:

objdump --syms build/gcc/jdk/lib/server/libjvm.so | grep gHotSpotVMTypeEntryIsIntegerTypeOffset
000000000137ca78 g     O .rodata	0000000000000008              gHotSpotVMTypeEntryIsIntegerTypeOffset

and I tested that the values are still readable. I was wondering if this wouldn't be portable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27362#discussion_r2359088177

From stefank at openjdk.org  Thu Sep 18 12:54:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Sep 2025 12:54:02 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v3]
In-Reply-To: <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
Message-ID: <KctQ6aUt5sASZROwpTPTYYHM8fq8w1Tq9NaaRgPrITM=.4c2ed88f-14e2-495a-9dd6-5e454d14fb3e@github.com>

On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27336#pullrequestreview-3239487734

From duke at openjdk.org  Thu Sep 18 12:57:48 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 12:57:48 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v2]
In-Reply-To: <tUujbYahWzDkOCtqv3P22OkM30BabUuH38DjqKCfqLM=.5f208643-c7ca-4523-9380-4c907ad72802@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <tUujbYahWzDkOCtqv3P22OkM30BabUuH38DjqKCfqLM=.5f208643-c7ca-4523-9380-4c907ad72802@github.com>
Message-ID: <cI1o1WI-qChTgqr-Lgfbdm7tCel8VZaSvCutUxBNsQ4=.c59b9b55-ee58-4e4a-ae9f-b30c91c57667@github.com>

On Wed, 17 Sep 2025 12:58:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367485: Refactoring with uint64_t
>
> src/hotspot/os/linux/os_linux.cpp line 545:
> 
>> 543:   }
>> 544:   const long int n_phys_pages = sysconf(_SC_PHYS_PAGES);
>> 545:   const long int page_size = sysconf(_SC_PAGESIZE);
> 
> How about just `long`, instead of `long int`?

I refactored everything in a different way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359117374

From stefank at openjdk.org  Thu Sep 18 13:21:59 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Sep 2025 13:21:59 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v2]
In-Reply-To: <OJY7K_8iqHsncWPwlbkEquMjWcrJg1BSK-A3wzCrOT8=.ac1f1c4c-3ab0-431e-b45e-47d7fd4b9c3f@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <OJY7K_8iqHsncWPwlbkEquMjWcrJg1BSK-A3wzCrOT8=.ac1f1c4c-3ab0-431e-b45e-47d7fd4b9c3f@github.com>
Message-ID: <n2lhMP_QX6ixSaBvxxBtRC9sA4qMql6onB8VjMrg9JI=.262c59f4-54a0-4c82-99a2-c678dad59213@github.com>

On Thu, 18 Sep 2025 12:51:39 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Refactoring with uint64_t

src/hotspot/os/linux/os_linux.cpp line 306:

> 304:     return false;
> 305:   }
> 306:   value = static_cast<uint64_t>(si.totalswap * si.mem_unit);

Could the `si.totalswap * si.mem_unit` calculation overflow on 32-bit JVMs? I wonder if it would be safer to write the code this way:

static_cast<uint64_t>(si.totalswap) * si.mem_unit;

The same comment goes for si.freeswap below.

src/hotspot/os/linux/os_linux.cpp line 2572:

> 2570:   struct sysinfo si;
> 2571:   sysinfo(&si);
> 2572:   uint64_t phys_mem = physical_memory();

You need to update the two `%zu` below.

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

> 3965: // Processor level is not available on non-NT systems, use vm_version instead
> 3966: int    os::win32::_processor_level           = 0;
> 3967: uint64_t os::win32::_physical_memory           = 0;

The indentation is misaligned now.

src/hotspot/os/windows/os_windows.hpp line 43:

> 41:   static int    _processor_type;
> 42:   static int    _processor_level;
> 43:   static uint64_t _physical_memory;

Indentation.

src/hotspot/share/gc/z/zLargePages.cpp line 34:

> 32:   pd_initialize();
> 33: 
> 34:   const uint64_t memory = os::physical_memory();

PROPERFMT below uses `%zu`. Given that ZGC is only compiled to 64-bits maybe you could make the memory variable size_t here. I don't know if you need an explicit cast or not.

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 534:

> 532:   EventPhysicalMemory event;
> 533:   event.set_totalSize(totalPhysicalMemory);
> 534:   uint64_t avail_mem = 0;

I think you can remove all usages of u8 in this function.

src/hotspot/share/runtime/os.cpp line 1948:

> 1946:   /* Is this a server class machine? */
> 1947:   if ((os::active_processor_count() >= (int)server_processors) &&
> 1948:       (phys_mem >= static_cast<uint64_t>(server_memory - missing_memory))) {

You don't need the cast if you change the type of `server_memory` and `missing_memory` to uint64_t instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359179008
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359191538
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359195029
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359196770
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359215587
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359221762
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359258332

From jsjolen at openjdk.org  Thu Sep 18 13:40:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 18 Sep 2025 13:40:16 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: <BhqTL2ei0sMifJXen0l8cLLrf0qta8Oa6LL4-3AgYYc=.ee7e45ce-9813-4a0d-8c31-5cb7992e9d18@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 jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26761#pullrequestreview-3239810539

From duke at openjdk.org  Thu Sep 18 13:49:59 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 13:49:59 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v3]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <rRsqxOenXrT0C63OMCmA4ivxjfKu-lBS9ckyeBxUOts=.0213b3c0-57ca-48b2-9840-07668a789a98@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/8e91019c..3c825e20

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

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

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

From duke at openjdk.org  Thu Sep 18 13:50:08 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 13:50:08 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v2]
In-Reply-To: <n2lhMP_QX6ixSaBvxxBtRC9sA4qMql6onB8VjMrg9JI=.262c59f4-54a0-4c82-99a2-c678dad59213@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <OJY7K_8iqHsncWPwlbkEquMjWcrJg1BSK-A3wzCrOT8=.ac1f1c4c-3ab0-431e-b45e-47d7fd4b9c3f@github.com>
 <n2lhMP_QX6ixSaBvxxBtRC9sA4qMql6onB8VjMrg9JI=.262c59f4-54a0-4c82-99a2-c678dad59213@github.com>
Message-ID: <Slng2kZSFkmTmQwCvnQziDis6Dn5ikNHoS7s7zp5vto=.ae25d9ae-9785-4f60-bc92-32e993872f4f@github.com>

On Thu, 18 Sep 2025 13:03:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367485: Refactoring with uint64_t
>
> src/hotspot/os/linux/os_linux.cpp line 306:
> 
>> 304:     return false;
>> 305:   }
>> 306:   value = static_cast<uint64_t>(si.totalswap * si.mem_unit);
> 
> Could the `si.totalswap * si.mem_unit` calculation overflow on 32-bit JVMs? I wonder if it would be safer to write the code this way:
> 
> static_cast<uint64_t>(si.totalswap) * si.mem_unit;
> 
> The same comment goes for si.freeswap below.

Yes it can, addressed as suggested.

> src/hotspot/os/linux/os_linux.cpp line 2572:
> 
>> 2570:   struct sysinfo si;
>> 2571:   sysinfo(&si);
>> 2572:   uint64_t phys_mem = physical_memory();
> 
> You need to update the two `%zu` below.

Right, somehow missed these two.

> src/hotspot/os/windows/os_windows.cpp line 3967:
> 
>> 3965: // Processor level is not available on non-NT systems, use vm_version instead
>> 3966: int    os::win32::_processor_level           = 0;
>> 3967: uint64_t os::win32::_physical_memory           = 0;
> 
> The indentation is misaligned now.

Addressed.

> src/hotspot/os/windows/os_windows.hpp line 43:
> 
>> 41:   static int    _processor_type;
>> 42:   static int    _processor_level;
>> 43:   static uint64_t _physical_memory;
> 
> Indentation.

I changed indentation of all members around, is that what you mean?

> src/hotspot/share/gc/z/zLargePages.cpp line 34:
> 
>> 32:   pd_initialize();
>> 33: 
>> 34:   const uint64_t memory = os::physical_memory();
> 
> PROPERFMT below uses `%zu`. Given that ZGC is only compiled to 64-bits maybe you could make the memory variable size_t here. I don't know if you need an explicit cast or not.

I prefer having explicit casting to avoid surprises in the future. Addressed.

> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 534:
> 
>> 532:   EventPhysicalMemory event;
>> 533:   event.set_totalSize(totalPhysicalMemory);
>> 534:   uint64_t avail_mem = 0;
> 
> I think you can remove all usages of u8 in this function.

Yes provided that u8 will always be uint64_t, which may or may not be true in the future. Removed as suggested.

> src/hotspot/share/runtime/os.cpp line 1948:
> 
>> 1946:   /* Is this a server class machine? */
>> 1947:   if ((os::active_processor_count() >= (int)server_processors) &&
>> 1948:       (phys_mem >= static_cast<uint64_t>(server_memory - missing_memory))) {
> 
> You don't need the cast if you change the type of `server_memory` and `missing_memory` to uint64_t instead.

Good point! Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359400370
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359402435
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359400620
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359401008
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359401382
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359401748
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359402021

From jsikstro at openjdk.org  Thu Sep 18 13:56:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 18 Sep 2025 13:56:08 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v3]
In-Reply-To: <rRsqxOenXrT0C63OMCmA4ivxjfKu-lBS9ckyeBxUOts=.0213b3c0-57ca-48b2-9840-07668a789a98@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <rRsqxOenXrT0C63OMCmA4ivxjfKu-lBS9ckyeBxUOts=.0213b3c0-57ca-48b2-9840-07668a789a98@github.com>
Message-ID: <Lciv0_bphfsvmG7qDYEFQxCHTkcP5J59wck8UIQb8-8=.d2ed5020-92a0-4fb5-bc0c-ddb15cf0230d@github.com>

On Thu, 18 Sep 2025 13:49:59 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Addressed reviewer's comments.

src/hotspot/share/runtime/os.cpp line 1944:

> 1942:   //     We allow some part (1/8?) of the memory to be "missing",
> 1943:   //     based on the sizes of DIMMs, and maybe graphics cards.
> 1944:   const uint64_t missing_memory   = 256UL * M;

There was some alignment going on here. Either we keep it or we might as well remove the spacing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359431693

From duke at openjdk.org  Thu Sep 18 14:02:00 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:02:00 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v4]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/3c825e20..7ac5f799

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

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

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

From duke at openjdk.org  Thu Sep 18 14:02:02 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:02:02 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v3]
In-Reply-To: <Lciv0_bphfsvmG7qDYEFQxCHTkcP5J59wck8UIQb8-8=.d2ed5020-92a0-4fb5-bc0c-ddb15cf0230d@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <rRsqxOenXrT0C63OMCmA4ivxjfKu-lBS9ckyeBxUOts=.0213b3c0-57ca-48b2-9840-07668a789a98@github.com>
 <Lciv0_bphfsvmG7qDYEFQxCHTkcP5J59wck8UIQb8-8=.d2ed5020-92a0-4fb5-bc0c-ddb15cf0230d@github.com>
Message-ID: <hg1lLIxYW2sFDfsf9hqyEXWT2YNZgXo0jb2KVkUPZBM=.f8631bfd-56df-41d5-b450-7d8726c81ad3@github.com>

On Thu, 18 Sep 2025 13:53:03 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:
>> 
>>   8367485: Addressed reviewer's comments.
>
> src/hotspot/share/runtime/os.cpp line 1944:
> 
>> 1942:   //     We allow some part (1/8?) of the memory to be "missing",
>> 1943:   //     based on the sizes of DIMMs, and maybe graphics cards.
>> 1944:   const uint64_t missing_memory   = 256UL * M;
> 
> There was some alignment going on here. Either we keep it or we might as well remove the spacing.

Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359460848

From stuefe at openjdk.org  Thu Sep 18 14:13:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Sep 2025 14:13:49 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: <VAFf37NxFDZ6k79sUVNCnLXYyKsiZFTauqjhRQtsb-g=.8bc8b23d-3fd0-4e52-bd5f-04225cdcfae2@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

Sorry for the delay, I was missing this one.

Good. Small nits inside, up to you if you take the suggestions. I don't need another review.

src/hotspot/os/linux/procMapsParser.cpp line 83:

> 81:   // scan THPeligible into a bool
> 82:   int thpel = 0;
> 83:   if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {

Suggestion:

  if (::sscanf(_line, "THPeligible: %d", &thpel) == 1) {
    assert(thpel == 1 || thpel == 0, "Unexpected value %d", thpel);

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 102:

> 100:             // metaspace
> 101:             regexBase_committed + "META.*",
> 102:             // parts of metaspace should be uncommitted, those parts can be thp eligible

Suggestion:

            // parts of metaspace should be uncommitted, those parts may or may not be be thp-eligible

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3240000359
PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2359510679
PR Review Comment: https://git.openjdk.org/jdk/pull/27098#discussion_r2359515522

From stefank at openjdk.org  Thu Sep 18 14:20:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Sep 2025 14:20:02 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v4]
In-Reply-To: <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
Message-ID: <uPrhZylLts-pm4w5GlSlW_TtAGU9YlfhDly0HVuKTUM=.05b9ee2f-4ef7-4f8c-b3a7-ce3464c75b5c@github.com>

On Thu, 18 Sep 2025 14:02:00 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Addressed reviewer's comments

One last nit, but otherwise this looks good to me. Please make sure to get review feedback from the other people that has been active in this PR.

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

> 3965: // Processor level is not available on non-NT systems, use vm_version instead
> 3966: int    os::win32::_processor_level           = 0;
> 3967: uint64_t os::win32::_physical_memory         = 0;

I suggest that you change the three variables to:

int      os::win32::_processor_type          = 0;
// Processor level is not available on non-NT systems, use vm_version instead
int      os::win32::_processor_level         = 0;
uint64_t os::win32::_physical_memory         = 0;

bool     os::win32::_is_windows_server       = false;

The proposed patch messes up the pre-existing alignment.

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

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3240038293
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359541576

From duke at openjdk.org  Thu Sep 18 14:35:49 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:35:49 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v5]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <VXtXU_ply2hjdUk3mjxT1OchNtU94XDdjB8eHPo0nBs=.672f0d5f-0808-499b-99af-38fe770f2c98@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

 - 8367485: Indentation fix.
 - 8367485: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/7ac5f799..bc4c8a06

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

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

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

From duke at openjdk.org  Thu Sep 18 14:35:53 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:35:53 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v4]
In-Reply-To: <uPrhZylLts-pm4w5GlSlW_TtAGU9YlfhDly0HVuKTUM=.05b9ee2f-4ef7-4f8c-b3a7-ce3464c75b5c@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
 <uPrhZylLts-pm4w5GlSlW_TtAGU9YlfhDly0HVuKTUM=.05b9ee2f-4ef7-4f8c-b3a7-ce3464c75b5c@github.com>
Message-ID: <Sw041UiuVeAYGgeljzFUsqMkhBUoWYw26fMJSSoyJdc=.b0ba4072-1125-40bf-81f5-2d702b959185@github.com>

On Thu, 18 Sep 2025 14:15:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367485: Addressed reviewer's comments
>
> src/hotspot/os/windows/os_windows.cpp line 3967:
> 
>> 3965: // Processor level is not available on non-NT systems, use vm_version instead
>> 3966: int    os::win32::_processor_level           = 0;
>> 3967: uint64_t os::win32::_physical_memory         = 0;
> 
> I suggest that you change the three variables to:
> 
> int      os::win32::_processor_type          = 0;
> // Processor level is not available on non-NT systems, use vm_version instead
> int      os::win32::_processor_level         = 0;
> uint64_t os::win32::_physical_memory         = 0;
> 
> bool     os::win32::_is_windows_server       = false;
> 
> The proposed patch messes up the pre-existing alignment.

Thanks, addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359609918

From stefank at openjdk.org  Thu Sep 18 14:42:29 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Sep 2025 14:42:29 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v5]
In-Reply-To: <VXtXU_ply2hjdUk3mjxT1OchNtU94XDdjB8eHPo0nBs=.672f0d5f-0808-499b-99af-38fe770f2c98@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <VXtXU_ply2hjdUk3mjxT1OchNtU94XDdjB8eHPo0nBs=.672f0d5f-0808-499b-99af-38fe770f2c98@github.com>
Message-ID: <aMVSUq_lGjUxUTSNj6dgI_Odv3sjfX6HYV3JOERI_mk=.dac3f5b9-1ff1-4b0d-bdd3-40ad467ff6db@github.com>

On Thu, 18 Sep 2025 14:35:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8367485: Indentation fix.
>  - 8367485: Addressed reviewer's comments.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3240191132

From stuefe at openjdk.org  Thu Sep 18 14:51:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Sep 2025 14:51:20 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v5]
In-Reply-To: <VXtXU_ply2hjdUk3mjxT1OchNtU94XDdjB8eHPo0nBs=.672f0d5f-0808-499b-99af-38fe770f2c98@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <VXtXU_ply2hjdUk3mjxT1OchNtU94XDdjB8eHPo0nBs=.672f0d5f-0808-499b-99af-38fe770f2c98@github.com>
Message-ID: <RQsoPx342KAFaCQomybsv9fEiywPFTEr_ox5dPe-Dy4=.0390dc0e-6c0b-46da-b758-0ecb1271c314@github.com>

On Thu, 18 Sep 2025 14:35:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8367485: Indentation fix.
>  - 8367485: Addressed reviewer's comments.

Ironically, the 32-bit build now fails. (tested with arm32).

Watch out for places where the newly typed vars are fed into `%zu`. Example below.

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

Changes requested by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3240141260

From stuefe at openjdk.org  Thu Sep 18 14:51:24 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 Sep 2025 14:51:24 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v4]
In-Reply-To: <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
Message-ID: <4HvxysvAi-I0N_s5ex4RLipQk3jIcg6zPeqxwJ6BIM0=.a1f5c0ea-5067-4552-bcfb-a3737295088b@github.com>

On Thu, 18 Sep 2025 14:02:00 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Addressed reviewer's comments

src/hotspot/share/gc/shared/gcInitLogger.cpp line 66:

> 64: void GCInitLogger::print_memory() {
> 65:   uint64_t memory = os::physical_memory();
> 66:   log_info_p(gc, init)("Memory: " PROPERFMT, PROPERFMTARGS(memory));

PROPERFMT uses %zu.

(If you change this, please keep PROPERFMT as it is. Just change this to raw uint64_t printing).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359623341

From duke at openjdk.org  Thu Sep 18 14:58:24 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:58:24 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v6]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <roFs17K8DfQJwbfy_jRxb7DwF7S4OiG05LsABxQDbUI=.7aa0643f-41df-4a4d-bd82-9fc750d534c8@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Addressed reviewers' comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/bc4c8a06..6ba90e10

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

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

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

From duke at openjdk.org  Thu Sep 18 14:58:29 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 14:58:29 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v4]
In-Reply-To: <4HvxysvAi-I0N_s5ex4RLipQk3jIcg6zPeqxwJ6BIM0=.a1f5c0ea-5067-4552-bcfb-a3737295088b@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <9axZ_JTxgMnIjf2WCfk6SFsCdaIDKwJIrhvY2cv4PYc=.b41bff57-e6b1-4865-8e6a-3d4a7ddafc05@github.com>
 <4HvxysvAi-I0N_s5ex4RLipQk3jIcg6zPeqxwJ6BIM0=.a1f5c0ea-5067-4552-bcfb-a3737295088b@github.com>
Message-ID: <R_lWF3la1cZaWdlrMw8EHHWM7Mphd1tdL4SGsYR3E6Q=.48b8387f-f4d6-4641-8e01-ca677cd791ea@github.com>

On Thu, 18 Sep 2025 14:31:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8367485: Addressed reviewer's comments
>
> src/hotspot/share/gc/shared/gcInitLogger.cpp line 66:
> 
>> 64: void GCInitLogger::print_memory() {
>> 65:   uint64_t memory = os::physical_memory();
>> 66:   log_info_p(gc, init)("Memory: " PROPERFMT, PROPERFMTARGS(memory));
> 
> PROPERFMT uses %zu.
> 
> (If you change this, please keep PROPERFMT as it is. Just change this to raw uint64_t printing).

Changed to `UINT64_FORMAT`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359728127

From jsikstro at openjdk.org  Thu Sep 18 15:01:44 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 18 Sep 2025 15:01:44 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v6]
In-Reply-To: <roFs17K8DfQJwbfy_jRxb7DwF7S4OiG05LsABxQDbUI=.7aa0643f-41df-4a4d-bd82-9fc750d534c8@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <roFs17K8DfQJwbfy_jRxb7DwF7S4OiG05LsABxQDbUI=.7aa0643f-41df-4a4d-bd82-9fc750d534c8@github.com>
Message-ID: <DZ21hpRuuHlh9D_8O8lJguMcd8XVhZ4GkGSXF9VeasE=.6bb52a00-ec64-42c8-8746-b28f1641f3f6@github.com>

On Thu, 18 Sep 2025 14:58:24 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Addressed reviewers' comments.

src/hotspot/share/gc/shared/gcInitLogger.cpp line 66:

> 64: void GCInitLogger::print_memory() {
> 65:   uint64_t memory = os::physical_memory();
> 66:   log_info_p(gc, init)("Memory: " UINT64_FORMAT, memory);

I don't think this is alright. We should just revert this to what it was before [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086), with UINT64_FORMAT instead.

log_info_p(gc, init)("Memory: " UINT64_FORMAT "%s",
                     byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));


Right now it looks like this:

[0.007s][info][gc,init] Memory: 38654705664

When it previously looked like this:

[0.023s][info][gc,init] Memory: 36864M

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359749983

From duke at openjdk.org  Thu Sep 18 15:08:36 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 15:08:36 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v7]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <iHs8htnGjjqh12Hmhy0Bg9DYmqmAiNd6fBREWNAdknk=.0135b5b7-144e-4349-8bb8-19113e4ab9eb@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Changed output format in GCInitLogger::print_memory()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/6ba90e10..2c67281b

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

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

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

From duke at openjdk.org  Thu Sep 18 15:08:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 15:08:39 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v6]
In-Reply-To: <DZ21hpRuuHlh9D_8O8lJguMcd8XVhZ4GkGSXF9VeasE=.6bb52a00-ec64-42c8-8746-b28f1641f3f6@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <roFs17K8DfQJwbfy_jRxb7DwF7S4OiG05LsABxQDbUI=.7aa0643f-41df-4a4d-bd82-9fc750d534c8@github.com>
 <DZ21hpRuuHlh9D_8O8lJguMcd8XVhZ4GkGSXF9VeasE=.6bb52a00-ec64-42c8-8746-b28f1641f3f6@github.com>
Message-ID: <S8qR21Q06IMLJo2Y2zU84pQjAvNJig_Spu8IvbsUdpU=.edc739b8-ffd9-40ba-be32-c1960513f00b@github.com>

On Thu, 18 Sep 2025 14:59:21 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:
>> 
>>   8367485: Addressed reviewers' comments.
>
> src/hotspot/share/gc/shared/gcInitLogger.cpp line 66:
> 
>> 64: void GCInitLogger::print_memory() {
>> 65:   uint64_t memory = os::physical_memory();
>> 66:   log_info_p(gc, init)("Memory: " UINT64_FORMAT, memory);
> 
> I don't think this is alright. We should just revert this to what it was before [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086), with UINT64_FORMAT instead.
> 
> log_info_p(gc, init)("Memory: " UINT64_FORMAT "%s",
>                      byte_size_in_proper_unit(memory), proper_unit_for_byte_size(memory));
> 
> 
> Right now it looks like this:
> 
> [0.007s][info][gc,init] Memory: 38654705664
> 
> When it previously looked like this:
> 
> [0.023s][info][gc,init] Memory: 36864M

Right, `UINT64_FORMAT` has nothing to do with units. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2359778976

From duke at openjdk.org  Thu Sep 18 15:15:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 18 Sep 2025 15:15:23 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v8]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <3PATnQIPnhoCbPBTb-CF5FOflkJ8c8BiORVCdJ-h-sc=.105e48da-228f-4de7-bf16-dfd3d3f827db@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Indentation in GCInitLogger::print_memory()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/2c67281b..23f62526

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

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

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

From jsjolen at openjdk.org  Thu Sep 18 15:55:34 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 18 Sep 2025 15:55:34 GMT
Subject: RFR: 8367987: Memory leak in MemBaseline: Must delete _vma_allocations
Message-ID: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>

Hi,

I forgot to add a destructor which deletes the `_vma_allocations` for JDK-8367249. This PR rectifies this mistake.

Thank you.

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

Commit messages:
 - Delete the VMA allocations by the end

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

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

From phubner at openjdk.org  Thu Sep 18 16:07:54 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 18 Sep 2025 16:07:54 GMT
Subject: RFR: 8367987: Memory leak in MemBaseline: Must delete
 _vma_allocations
In-Reply-To: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
References: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
Message-ID: <B-O76Vyg-nC2g41CJQ2VTpJyUiLFIm9wU9bA35CzpAk=.8a1e84f8-df2f-4a53-97cf-3b45e61ae36a@github.com>

On Thu, 18 Sep 2025 13:22:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I forgot to add a destructor which deletes the `_vma_allocations` for JDK-8367249. This PR rectifies this mistake.
> 
> Thank you.

Marked as reviewed by phubner (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27364#pullrequestreview-3240711846

From kirk at kodewerk.com  Thu Sep 18 16:51:58 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Thu, 18 Sep 2025 09:51:58 -0700
Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
 <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
Message-ID: <34CF9C0B-5D79-40D9-AC37-4760C601558F@kodewerk.com>

Hi all,

I have to strongly agree with Erik on this point. Going from one ?guess? to another doesn?t seem like a good solution to this question. We have deep experience with the current ?guess?. Much of what we have has been built around this ?guess?. To change this ?guess? to another ?guess? risks breaking everything that has been built on the previous guess. 

One of the confusions that I?ve seen and have tried to educate towards a better understanding is the difference between virtual and real memory (address spaces). The risk here is that if you give Java heap a new default setting then you will be committing more real memory and this will have an impact on those relying of defaults in that they will immediately need more real memory because if you give Java heap more memory, it will use it. If you want to OOM a significant number of apps that are relying on defaults, then a great way to do this is to change the default to a larger value.

Kind regards,
Kirk


> On Sep 18, 2025, at 2:03?AM, Erik ?sterlund <eosterlund at openjdk.org> wrote:
> 
> On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
> 
>> Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory).
>> 
>> I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour.
>> 
>> Testing:
>> - [x] GHA - tier 1 (windows failures seem infra related)
>> - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests.
>> 
>> Thoughts? Opinions?
> 
> The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer. 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want. But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB. 
> 
> I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about *why* a limit is too high or too low, and adapting accordingly at runtime.
> 
> When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses? If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3306363643


From sgehwolf at openjdk.org  Thu Sep 18 17:26:24 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Sep 2025 17:26:24 GMT
Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
 <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
Message-ID: <X4YsF9rEs0tnzYI1V03-CP2PfhYk9DUktoW_xKDX9SA=.581249e1-2572-4a55-aa7b-394bb6c7de38@github.com>

On Thu, 18 Sep 2025 09:00:23 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The question how much heap memory an arbitrary Java program needs to run is in many ways similar to the halting problem of answering how much time a Java program needs to run. There is no great answer.

Agreed. Nevertheless there is a problem worth solving: Improve the memory *utilization* issue of Java when deploying to the cloud. This isn't a *performance* measure. It should be performance neutral. The goal would be to improve the memory utilization story in the default config.

> 25% was a wild guess. Sometimes it's okay, sometimes it is awful. There are plenty of situations when it is not at all what you want.

At the time container deployments with a single process in it weren't a thing. They are now.

> But I'm very skeptical against coming up with a new wild guess hoping to improve performance, while risking getting killed. In a 512 MB container, 25% might be too small and you really want to use 75% to get better performance, except when direct mapped byte buffers use too much memory. But in a 128 MB container, 75% might be too much as the JIT compiled code and meatspace might need more than 32 MB.

We have more data now, so the default should adjust. Keep in mind that the proposal is to change the `MaxRAMPercentage` value in a fairly specific setup: in a container with a memory limit set on the container level. Since this is changing only `MaxRAMPercentage` it feeds into the heuristics machinery in determining the actual `MaxHeapSize`. I've attached two charts to the bug showing that the `MaxRAMPercentage` bump has no effect on JVMs with 250MB of memory or less.
 
> I think trying to find a good answer to how much heap a Java should use without running it is hopeless, and don't feel thrilled about changing the guesses from one bad guess to another bad guess, rather than having a more complete way of reasoning about _why_ a limit is too high or too low, and adapting accordingly at runtime.

Hopeless seems a stretch. I'm arguing we have more data (today) and we need to think about how to slowly adjust the defaults to the new normal.

> When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses?

I think so. While those JEP drafts are really heading in the right direction, it doesn't solve the problem for the rest of the GCs. Keep in mind that for many small deployments, say 1 core, you'd get Serial GC, not solving the problem there.

> If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead.

I agree that automatic heap sizing should solve this problem. But it needs to do so for all cases. Also, it's not clear when those JEPs will be widely available. Until that's the case we should try to adjust defaults to the changed reality to ease some of this pain.

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

PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3308676336

From eosterlund at openjdk.org  Thu Sep 18 19:25:57 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 18 Sep 2025 19:25:57 GMT
Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <X4YsF9rEs0tnzYI1V03-CP2PfhYk9DUktoW_xKDX9SA=.581249e1-2572-4a55-aa7b-394bb6c7de38@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
 <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
 <X4YsF9rEs0tnzYI1V03-CP2PfhYk9DUktoW_xKDX9SA=.581249e1-2572-4a55-aa7b-394bb6c7de38@github.com>
Message-ID: <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com>

On Thu, 18 Sep 2025 17:23:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > When these sort of proposals started popping up, I started working on automatic heap sizing instead so that we would be able to recognize that there is actually no static limit if the user hasn't said so, but we can deal with that without exhausting memory with some clever policies. Now there is a JEP for both ZGC (cf. https://openjdk.org/jeps/8329758) and G1 (cf. https://openjdk.org/jeps/8359211) to do automatic heap sizing. Given their arrival, do we still need to mess around with these guesses?
> 
> 
> 
> I think so. While those JEP drafts are really heading in the right direction, it doesn't solve the problem for the rest of the GCs. Keep in mind that for many small deployments, say 1 core, you'd get Serial GC, not solving the problem there.

This default quirk is fixed with https://openjdk.org/jeps/523 which makes G1 default where Serial is today.

> 
> 
> > If not, then I think changing from one bad guess to another bad guess might just introduce risk. I'd prefer to let automatic heap sizing solve this better instead.
> 
> 
> 
> I agree that automatic heap sizing should solve this problem. But it needs to do so for all cases. Also, it's not clear when those JEPs will be widely available. Until that's the case we should try to adjust defaults to the changed reality to ease some of this pain.

They are pretty far along.

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

PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3309269956

From iklam at openjdk.org  Fri Sep 19 01:07:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Sep 2025 01:07:17 GMT
Subject: RFR: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <MqbyZ4aloYoi4GUQtt8qLxJEpw-0SMKxdXpPnDvc_Ug=.cffd63ee-9bac-4ca3-b91f-394c7a9dd898@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
 <MqbyZ4aloYoi4GUQtt8qLxJEpw-0SMKxdXpPnDvc_Ug=.cffd63ee-9bac-4ca3-b91f-394c7a9dd898@github.com>
Message-ID: <ZhrOeyHySybE-OUKTnIFmqruh4hj1DfbLfcnW_sY2CI=.6304f57a-7ee4-497f-83f7-dcf24eb47137@github.com>

On Wed, 17 Sep 2025 09:49:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
>> 
>> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.
>
> I remember reviewing this in Leyden/premain downstream. This looks good for mainline.

Thanks @shipilev @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27323#issuecomment-3310134345

From iklam at openjdk.org  Fri Sep 19 01:07:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Sep 2025 01:07:18 GMT
Subject: Integrated: 8362657: Make tables used in AOT assembly phase GC-safe
In-Reply-To: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
References: <qHIZqP1KdcI20Cf35lNWPxGuaerHoFO_aNeVX7hQ-Ao=.1d9e558e-302d-4229-b3ab-d449c259b778@github.com>
Message-ID: <rQEmzNQO0FIJ8tJMQTqcVAV9Qx7l0ZMZk-PaitnZjyM=.7d3019db-a18b-491d-98fd-90e86c73ddf9@github.com>

On Tue, 16 Sep 2025 20:42:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Upstreaming from the Leyden prototype in anticipation of AOT code compilation ([JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368)).
> 
> We have a few tables that are currently consulted only inside the CDS safepoint. With AOT code compilation, these tables may be consulted after we leave the CDS safepoint. For GC safety, this PR uses `OopHandle` instead of `oop` in hashtables.

This pull request has now been integrated.

Changeset: e3a4c284
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3a4c28409ac62feee9efe069e3a3482e7e2cdd2
Stats:     86 lines in 7 files changed: 62 ins; 0 del; 24 mod

8362657: Make tables used in AOT assembly phase GC-safe

Reviewed-by: shade, dholmes

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

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

From sjohanss at openjdk.org  Fri Sep 19 07:10:36 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 07:10:36 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v4]
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: <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@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:

  Thomas review
  
  Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27098/files
  - new: https://git.openjdk.org/jdk/pull/27098/files/d9aa3c29..7b3d9f93

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

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 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 19 07:10:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 07:10:38 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v3]
In-Reply-To: <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <WP8d8TQGEa4CBoLoqRLZfSW5um69fk1k75EHVWdjEmE=.0298340f-85a5-45f3-b032-1397d15d0e70@github.com>
 <Jj7iJXaT6bJfBqfMRstEFwbT6rcVYVmosVnHNPIW5Dw=.9b9c60dc-96e2-49e7-8ca0-df4fe4dfc8c3@github.com>
Message-ID: <5FvVmBPrBoK5ADJlt3xk9V4688o6m1Ga7jQd20Jqsko=.795c4183-98ca-4108-9bc4-f887cb0740c2@github.com>

On Fri, 5 Sep 2025 09:24:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks for the reviews @albertnetymk and @tstuefe. Will need a re-review since I applied the suggestions above.

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

PR Comment: https://git.openjdk.org/jdk/pull/27098#issuecomment-3310926625

From tschatzl at openjdk.org  Fri Sep 19 07:24:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 19 Sep 2025 07:24:49 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v3]
In-Reply-To: <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
Message-ID: <YYEm1e3qjuvThH7kfldyt2PC9Z9gyyu_1MQWgDTL3MQ=.bbb22417-a677-49c2-8c32-a944e998e24e@github.com>

On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27336#pullrequestreview-3243540019

From azafari at openjdk.org  Fri Sep 19 07:41:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 19 Sep 2025 07:41:09 GMT
Subject: RFR: 8367987: Memory leak in MemBaseline: Must delete
 _vma_allocations
In-Reply-To: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
References: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
Message-ID: <h0OEoZaoun1bB-jR4Fw78WvhvMm--0e3qoEG8UQVK-U=.54ff1d04-923c-4ab6-adb6-d603885fb3f7@github.com>

On Thu, 18 Sep 2025 13:22:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I forgot to add a destructor which deletes the `_vma_allocations` for JDK-8367249. This PR rectifies this mistake.
> 
> Thank you.

LGTM. Thanks.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27364#pullrequestreview-3243596406

From ayang at openjdk.org  Fri Sep 19 07:42:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 19 Sep 2025 07:42:27 GMT
Subject: RFR: 8367848: Parallel: Use NMethodToOopClosure during Young GC
 [v3]
In-Reply-To: <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
 <JrBDtZIWMt-DxYuMuKyp-Nz42A2IrTBj5Jbs2uFhvq0=.a7d0e14a-a263-44fd-92f9-3f5885a2c8ea@github.com>
Message-ID: <OO_tYpv9ng-_afjefEw52rwKoIob7gusxgKF-4mcYwg=.8d425f80-8a4d-45ec-88e4-671aa6b8a1cf@github.com>

On Thu, 18 Sep 2025 09:04:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27336#issuecomment-3311000949

From ayang at openjdk.org  Fri Sep 19 07:42:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 19 Sep 2025 07:42:28 GMT
Subject: Integrated: 8367848: Parallel: Use NMethodToOopClosure during Young GC
In-Reply-To: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
References: <1junjLjTWzIsXHpwN7aXUvGSrRafJPP-LBUA3ZsQnDM=.21c925ae-d5b6-486b-be19-33fbe865b994@github.com>
Message-ID: <BwsAjZH4n6CyHc08omK1BoNasnx9Yq3WHHVZORs-I3o=.e6c8fe30-8a31-43de-9ee7-ce38d6523880@github.com>

On Wed, 17 Sep 2025 09:00:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Replace `MarkingNMethodClosure` with `NMethodToOopClosure` during young-gc. After that, a new local `ThreadsClaimTokenScope` is introduced instead of `StrongRootsScope` to make the thread-claim-token logic visible in the current context.
>  
> Test: tier1-3

This pull request has now been integrated.

Changeset: 28879d3d
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28879d3d03ca6e8ea68a6063da349d83310b22ce
Stats:     13 lines in 2 files changed: 10 ins; 0 del; 3 mod

8367848: Parallel: Use NMethodToOopClosure during Young GC

Reviewed-by: stefank, tschatzl

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

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

From jsikstro at openjdk.org  Fri Sep 19 07:53:41 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Sep 2025 07:53:41 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v8]
In-Reply-To: <3PATnQIPnhoCbPBTb-CF5FOflkJ8c8BiORVCdJ-h-sc=.105e48da-228f-4de7-bf16-dfd3d3f827db@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <3PATnQIPnhoCbPBTb-CF5FOflkJ8c8BiORVCdJ-h-sc=.105e48da-228f-4de7-bf16-dfd3d3f827db@github.com>
Message-ID: <eOwUnHitCy48mHxVuZOSGeIB4HwTsdOvi-dzrNMvF1w=.a3379043-f9c4-4c6b-8961-18c353d6e7f4@github.com>

On Thu, 18 Sep 2025 15:15:23 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Indentation in GCInitLogger::print_memory()

Great work! I have a small suggestion below, otherwise I think this looks good.

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

> 3967: uint64_t os::win32::_physical_memory           = 0;
> 3968: 
> 3969: bool     os::win32::_is_windows_server         = false;

Continuing on Stefan's suggestion, we should also align them with the static variables below.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3243561494
PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2362038900

From duke at openjdk.org  Fri Sep 19 08:01:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 19 Sep 2025 08:01:44 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v9]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

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

  8367485: Alignment of vars in os_windows.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/23f62526..791faaeb

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

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

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

From duke at openjdk.org  Fri Sep 19 08:01:46 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 19 Sep 2025 08:01:46 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v8]
In-Reply-To: <eOwUnHitCy48mHxVuZOSGeIB4HwTsdOvi-dzrNMvF1w=.a3379043-f9c4-4c6b-8961-18c353d6e7f4@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <3PATnQIPnhoCbPBTb-CF5FOflkJ8c8BiORVCdJ-h-sc=.105e48da-228f-4de7-bf16-dfd3d3f827db@github.com>
 <eOwUnHitCy48mHxVuZOSGeIB4HwTsdOvi-dzrNMvF1w=.a3379043-f9c4-4c6b-8961-18c353d6e7f4@github.com>
Message-ID: <bIH6ibB7KPS8wIFE7YWJDhvegtjo0i9k6EGD-uEKtB8=.13c16306-7bee-4e6b-a521-6e478546f2c6@github.com>

On Fri, 19 Sep 2025 07:29:34 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:
>> 
>>   8367485: Indentation in GCInitLogger::print_memory()
>
> src/hotspot/os/windows/os_windows.cpp line 3969:
> 
>> 3967: uint64_t os::win32::_physical_memory           = 0;
>> 3968: 
>> 3969: bool     os::win32::_is_windows_server         = false;
> 
> Continuing on Stefan's suggestion, we should also align them with the static variables below.

Rather, align the vars below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2362100110

From stuefe at openjdk.org  Fri Sep 19 08:08:23 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 19 Sep 2025 08:08:23 GMT
Subject: RFR: 8366780: Enhance ProcSmapsParser and Printer to handle
 THPeligible field [v4]
In-Reply-To: <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@github.com>
References: <IhzK0xw6ZZN9xTN2tRFji23uy-iYrxOC-FVvPU5DjCA=.fd7419d7-45e1-4f59-8f87-076bbdad074d@github.com>
 <OcgKVUeBKMbMK8P87BbGbCyVT4YxCsj_yfibBzqb3Ao=.830efb36-8175-4474-bcd0-a70ff2cf0511@github.com>
Message-ID: <Va9cm-ulXrPO9cH1v612zBrsrAzuW3eNPuZ49J9jJDg=.f864e7f3-5323-4fef-a06c-d7de3a8cda75@github.com>

On Fri, 19 Sep 2025 07:10:36 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:
> 
>   Thomas review
>   
>   Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>

Still good

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27098#pullrequestreview-3243690046

From stefank at openjdk.org  Fri Sep 19 08:28:14 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Sep 2025 08:28:14 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v9]
In-Reply-To: <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
Message-ID: <2iowPp5_Y-ztqr6Af6xDqj2c_qPeSADnFz0ixX70YF8=.ed3a7dd5-ce77-4352-a25c-d6093392c6a7@github.com>

On Fri, 19 Sep 2025 08:01:44 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Alignment of vars in os_windows.cpp

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3243757035

From sjohanss at openjdk.org  Fri Sep 19 08:52:01 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 19 Sep 2025 08:52:01 GMT
Subject: Integrated: 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: <Bb-dYMzxjH5duGPaIf6IrWnqWKCy26ybUIvC85g1Vko=.2dfa81f8-b24c-4ce2-be4c-3598685c8ad5@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.

This pull request has now been integrated.

Changeset: 937e19e8
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/937e19e86aab9194c363fb8709bbbc6dead0c391
Stats:     16 lines in 4 files changed: 12 ins; 1 del; 3 mod

8366780: Enhance ProcSmapsParser and Printer to handle THPeligible field

Reviewed-by: stuefe, ayang

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

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

From sgehwolf at openjdk.org  Fri Sep 19 09:45:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 19 Sep 2025 09:45:51 GMT
Subject: Withdrawn: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
Message-ID: <QV0MgXTUUMAMnqc9z-28PBsWEGoXC_hwF2Dub1ivZsU=.22594afb-c0c2-4c58-92fc-36928a776728@github.com>

On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory).
> 
> I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour.
> 
> Testing:
> - [x] GHA - tier 1 (windows failures seem infra related)
> - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests.
> 
> Thoughts? Opinions?

This pull request has been closed without being integrated.

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

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

From sgehwolf at openjdk.org  Fri Sep 19 09:45:50 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 19 Sep 2025 09:45:50 GMT
Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for
 containerized workloads
In-Reply-To: <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com>
References: <z8KjvE2-6-45QzmUulkhC_TkHrSnq4BzkqFhWs5oK4E=.9c0d62da-eb58-4909-9dd9-b5a6de49483f@github.com>
 <1S38JYoE4Gclx8Cv0NOWFjFWgTj_4q2eqG4rhaZ2k1M=.024810d5-5829-475d-8526-5c99fded9466@github.com>
 <X4YsF9rEs0tnzYI1V03-CP2PfhYk9DUktoW_xKDX9SA=.581249e1-2572-4a55-aa7b-394bb6c7de38@github.com>
 <9Rn-BfvWiEjwdJb2odC3W-kD4NhAHTXmDXNbFEqFD2I=.8171a0aa-e723-4c33-a533-9df0d6d42db3@github.com>
Message-ID: <pI0fOwzAcGbCF2m2dHKo0XV6Q2lDPe9t9M3a3tnvXcM=.a9c76304-2c7e-47aa-aaf1-de686b8c4caf@github.com>

On Thu, 18 Sep 2025 19:21:21 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> This default quirk is fixed with https://openjdk.org/jeps/523 which makes G1 default where Serial is today.

Ah ok. I'll withdraw then. Thanks for the additional context on the various JEPs/JEP drafts. Useful.

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

PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-3311480854

From duke at openjdk.org  Fri Sep 19 14:12:13 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:12:13 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
Message-ID: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>

`jcmd` provides great diagnostics but many commands lack a timestamp in their output.
Adding a timestamp to the output of some would add value for those debugging JVM data.

Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.

Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.

The exceptions are:
* `VM.uptime` - command run with `-date` argument will also print a timestamp;
* `VM.system_properties` - already lists timestamp
* `Thread.dump_to_file` - the content dumped to file already has a timestamp;
* `VM.version`

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

Commit messages:
 - copyright change
 - Thread.dump_to_file doesn't need timestamp in STDOUT
 - CodeCacheTest.java and ClassHierarchyTest.java to account for added timestamp
 - jcmd [PID] Compiler.perfmap has no valuable stdout. Remove timestamp from Compiler.perfmap
 - 8357828: add timestamps to jcmd diagnostic commands

Changes: https://git.openjdk.org/jdk/pull/27368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357828
  Stats: 45 lines in 4 files changed: 38 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368

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

From alanb at openjdk.org  Fri Sep 19 14:12:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Sep 2025 14:12:15 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

src/hotspot/share/services/diagnosticCommand.cpp line 1093:

> 1091: 
> 1092: void ThreadDumpToFileDCmd::execute(DCmdSource source, TRAPS) {
> 1093:   print_local_time(output());

I assume you didn't mean to print a time stamp here as the output already has a timestamp. Also for -format=json and sending the output to stdout, then it will be unparsable if a timestamp appears before the JSON object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27368#discussion_r2361986465

From duke at openjdk.org  Fri Sep 19 14:12:15 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:12:15 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <mrItWSSx-0HdN3H5sOt0E89ep28sjp7qHOE0s6KOyuU=.7a9eced4-6211-4dab-8468-137e8116a634@github.com>
Message-ID: <vYmNnzzS3b8HTA0Tv0CpOVH2itoGd244TPbd5BIbzY0=.304f800e-a464-42b6-91d1-9307b0742868@github.com>

On Fri, 19 Sep 2025 07:02:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
>> Adding a timestamp to the output of some would add value for those debugging JVM data.
>> 
>> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
>> 
>> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
>> 
>> The exceptions are:
>> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
>> * `VM.system_properties` - already lists timestamp
>> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
>> * `VM.version`
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1093:
> 
>> 1091: 
>> 1092: void ThreadDumpToFileDCmd::execute(DCmdSource source, TRAPS) {
>> 1093:   print_local_time(output());
> 
> I assume you didn't mean to print a time stamp here as the output already has a timestamp. Also for -format=json and sending the output to stdout, then it will be unparsable if a timestamp appears before the JSON object.

Hi Alan. That's right.
My mistake. I declared the intention to not have timestamps for commands with a throwaway `stdout`. This also includes "Thread.dump_to_file" command but then mistakenly added `print_local_time()` in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27368#discussion_r2362306527

From duke at openjdk.org  Fri Sep 19 14:16:01 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 19 Sep 2025 14:16:01 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <oMzEa3-aVReKjwNsRaDHJ2x7XGPiaKOHEzR4Bu-cN2Q=.b6aba967-8699-44e7-a9d3-d083777f2571@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Internal testing tier 1-5 did not show any issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3312364497

From stuefe at openjdk.org  Sat Sep 20 07:24:16 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 20 Sep 2025 07:24:16 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v9]
In-Reply-To: <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
Message-ID: <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com>

On Fri, 19 Sep 2025 08:01:44 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
>> 
>> The issue is addressed by changing the output type of all related functions to `uint64_t`.
>> 
>> Tested in tiers 1 - 5.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367485: Alignment of vars in os_windows.cpp

I am okay with this, albeit hesitatingly.

I think this worsens the code quality and is prone to bitrot. `size_t` carries a meaning: it is generally understood to be a measurement for a memory size, even though in hotspot it often gets misused for counters. That was the underlying reason for the original size_t change.

We now have a distinction between reported memory size and size of memory the process can address, and some APIs return the former now whereas the bulk of APIs works with the latter. The distinction is obfuscated by using a plain `uint64_t`, it could be made more explicit (and later cleanup after 32-bit has gone would be easier) with something like `typedef uint64_t physical_memory_size_t`.

But other reviewers are okay with this and I don't want to hold up this change. In any case, thanks for taking care of this  @toxaart - dealing with opinion-laden issues like this is never fun.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3248812961

From iklam at openjdk.org  Sun Sep 21 00:16:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 21 Sep 2025 00:16:38 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
Message-ID: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>

This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.

### Background:

The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.

As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.

Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.

### Problem:

The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.

### Fix:

If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.

As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

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

Commit messages:
 - updated javadoc for AOTSafeClassInitializer.java
 - Fix
 - imported

Changes: https://git.openjdk.org/jdk/pull/27402/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27402&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368174
  Stats: 288 lines in 11 files changed: 196 ins; 47 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/27402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27402/head:pull/27402

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

From dzhang at openjdk.org  Sun Sep 21 10:58:50 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Sun, 21 Sep 2025 10:58:50 GMT
Subject: RFR: 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()
Message-ID: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>

Hi,
Can you help to review this patch? Thanks!

We can clean up the duplicate call to ext_Zicboz.enable_feature() in VM_Version::rivos_features(), as it is already invoked at https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L286

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

Commit messages:
 - 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()

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

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

From iklam at openjdk.org  Sun Sep 21 20:07:43 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 21 Sep 2025 20:07:43 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
Message-ID: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>

The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.

However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.

The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.

Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

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

Commit messages:
 - 8368182: AOT cache creation fails with class defined by JNI

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

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

From fyang at openjdk.org  Mon Sep 22 01:01:25 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 22 Sep 2025 01:01:25 GMT
Subject: RFR: 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()
In-Reply-To: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
References: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
Message-ID: <WzGUiPFCh4crSz9AobV-BMtOU85bzPV18QcA4UaBP3k=.e98b7d6c-376b-45f8-8cb4-8e0daaeb3c9f@github.com>

On Sun, 21 Sep 2025 10:52:28 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> We can clean up the duplicate call to ext_Zicboz.enable_feature() in VM_Version::rivos_features(), as it is already invoked at https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L286

LGTM. Thanks.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27409#pullrequestreview-3250252328

From dholmes at openjdk.org  Mon Sep 22 05:47:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Sep 2025 05:47:20 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <7rpaBfLKYrVBVoKTcuPEpSKZR1dMmWxTuvU6UwIdKbc=.d556dd74-ede0-4588-a57c-532ed7852fb4@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints timestamp in a "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

This was raised and discussed somewhere else not that long ago, but I don't recall where and it fizzled out as I recall. But I will re-raise the issues - what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? The value of a timestamp on dmcd output is to allow it to be placed in chronological order relative to other output - so you need to be able to match the "timestamp" of that other output.

And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). That way users opt-in and we don't have to remember to add this for new Dcmds.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3317032230

From jsjolen at openjdk.org  Mon Sep 22 07:19:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 22 Sep 2025 07:19:07 GMT
Subject: Integrated: 8367987: Memory leak in MemBaseline: Must delete
 _vma_allocations
In-Reply-To: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
References: <mHe02mDF4Pi0oe1wSYHhOU2dhWqcVhMRTy-uvRRcoNo=.838fdf38-478c-49ec-a759-3689719a9ea5@github.com>
Message-ID: <ZWov8ksUgICnH3eXZLtN2LQ9pPIH9WJOUWQVvVmC8Z0=.5e079622-c08b-4cce-b887-4bcf187cdb8b@github.com>

On Thu, 18 Sep 2025 13:22:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I forgot to add a destructor which deletes the `_vma_allocations` for JDK-8367249. This PR rectifies this mistake.
> 
> Thank you.

This pull request has now been integrated.

Changeset: 258fcf9f
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/258fcf9f5ea089891f0119bbf8058da389f72321
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8367987: Memory leak in MemBaseline: Must delete _vma_allocations

Reviewed-by: phubner, azafari

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

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

From dholmes at openjdk.org  Mon Sep 22 07:42:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 Sep 2025 07:42:31 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
In-Reply-To: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
Message-ID: <eRSgNCnt2_GrAGGhFNcx0aQsbygiI1fI-UZ3KNQXxMY=.fdba5c6e-c231-4b7a-8f06-197c1610b1c8@github.com>

On Sun, 21 Sep 2025 20:00:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
> 
> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
> 
> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
> 
> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

So where were these JNI defined classes originating from when you saw the failures?

src/hotspot/share/classfile/classLoader.cpp line 1196:

> 1194:   if (src == nullptr) {
> 1195:     if (loader == nullptr) {
> 1196:       // JFR classes

What was this referring to? I traced this back to "8186842: Use Java class loaders for creating the CDS archive" but no mention of any JFR classes was made. FWIW I can't see any use of JNI DefineClass in the JDK code, so this change would only affect end-user code.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JNIDefineClass.java line 128:

> 126: }
> 127: 
> 128: // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DefineClass() with a null code source,

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JNIDefineClass.java line 134:

> 132: }
> 133: 
> 134: // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DefineClass() with a null code source,

Suggestion:

// This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

test/hotspot/jtreg/runtime/cds/appcds/aotCache/libJNIDefineClassApp.c line 34:

> 32:     jclass returnValue = (*env)->DefineClass(env, classNameChar, classLoader, arrayContent, bytecodeLength);
> 33:     (*env)->ReleaseByteArrayElements(env, bytecode, arrayContent, JNI_ABORT);
> 34:     (*env)->ReleaseStringUTFChars(env, className, classNameChar);

Does this pass `-Xcheck:jni`? ie. do you need to check for exceptions in the above sequence.

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

PR Review: https://git.openjdk.org/jdk/pull/27412#pullrequestreview-3250774051
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366846765
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366844318
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366844859
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2366843584

From ayang at openjdk.org  Mon Sep 22 08:07:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 22 Sep 2025 08:07:19 GMT
Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask
In-Reply-To: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com>
References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com>
Message-ID: <TbPYQWRC_oYQ64O7H0AFhSNJ-PL4iyLjNRYeKp3ZWhY=.d490fdc4-6d21-4c97-917d-4573bcc9bddf@github.com>

On Tue, 16 Sep 2025 15:54:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to parallel klass cleaning to improve performance.
> 
> The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads.
> 
> Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads).
> 
> The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass.
> 
> E.g.
> 
> CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4;
> vertical links are subklass references, while horizontal links are sibling references.
> 
> j.l.O
>   |
>   A - B - c - 3
>   |
>   0 - 2 - C - 1
> 
> 
> CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead).
> 
> So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`.
> Thread 2 will only remove the link to `3` of `c`.
> 
> The result is
> 
> j.l.O
>   |
>   A - B - c
>   |
>   C
> 
> 
> There should be no unnecessary object graph walking.
> 
> There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print
> 
> 
> unlinking class (subclass): 0
> unlinking class (subclass): 2
> 
> 
> With the change, to avoid following the subklasses of the graph twice, it prints
> 
> 
> ?unlinking class (subclass): 0
> unlinking class (sibling): 0
> 
> 
> because the string in brackets is the actual link that is followed. I can revert that change.
> 
> With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Preexisting: These two methods, `subklass` and `next_sibling`, sounds like plain getters, but they actually query liveness and skip dead klasses. I wonder whether it's possible to prune dead klasses in one go at some place and turn these two methods into plain getters.

src/hotspot/share/gc/shared/parallelCleaning.hpp line 57:

> 55: // Cleans out the Klass tree from stale data.
> 56: class KlassCleaningTask : public StackObj {
> 57:   ClassLoaderDataGraphIteratorAtomic _cld_iterator;

I suggest adding `_atomic` suffix to the field name.

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

PR Review: https://git.openjdk.org/jdk/pull/27316#pullrequestreview-3250946195
PR Review Comment: https://git.openjdk.org/jdk/pull/27316#discussion_r2366965395

From adinn at openjdk.org  Mon Sep 22 09:22:24 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 22 Sep 2025 09:22:24 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <6-YD1r_VNTgkNLBn7M11IdwnKHKWuFV3VMxwyF1Wsao=.18e5aa0f-6fee-4df1-a2e3-54c84a14133f@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

src/hotspot/share/cds/aotClassInitializer.cpp line 294:

> 292:     });
> 293:   } else {
> 294:     // @AOTRuntimeSetup only meaningful in @AOTClassInitializer

Suggestion:

    // @AOTRuntimeSetup only meaningful in @AOTSafeClassInitializer

src/hotspot/share/cds/aotMetaspace.cpp line 815:

> 813:     FinalImageRecipes::apply_recipes(CHECK);
> 814: 
> 815:     // Because the AOT assembly phase does not run the exact code as in the

Suggestion:

    // Because the AOT assembly phase does not run the exact same code as in the

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2367248414
PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2367251255

From adinn at openjdk.org  Mon Sep 22 09:37:34 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 22 Sep 2025 09:37:34 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <C2G9O_wj4XdULaMIg8-JhxYTZxGZVb76SOB2pKFBAdw=.62402778-fce1-4957-a778-c15d8a22d5cb@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java line 45:

> 43: ///   _X_ can still be triggered by normal execution of Java code in the assembly phase.
> 44: ///   This is usually the result of performing AOT optimizations for the
> 45: ///   `java.lang.invoke` package.

Suggestion:

///   At present this is usually the result of performing AOT optimizations for
///   the `java.lang.invoke` package but the set of classes which may be
///   pre-initialized via this annotation is not restricted to just that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2367293125

From adinn at openjdk.org  Mon Sep 22 09:40:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 22 Sep 2025 09:40:40 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <AtxrrHnkKSR0Wt4sFYmM0ZHl6QVhPcOPQVyX-Hrgve8=.dd1b532c-0119-4fcb-8b4c-96a87443b812@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

This is much simpler and clearer than the previous version making it easier for non-Leyden devs to understand what they are buying into when they use the annotation. Nice work @ashu-mehra and @iklam.
I made a few suggestions to clarify comments which you are free to adopt or drop as you see fit. Otherwise looks good to go.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27402#pullrequestreview-3251443606

From coffeys at openjdk.org  Mon Sep 22 11:24:34 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 22 Sep 2025 11:24:34 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <K_RN1gRkQ5FN2jKz8X2Yx3bHB9YJBTaxqPV06LfCIPA=.00fc2e19-4c30-4c62-88f2-5e98071bd407@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

The Thread.print dcmd already uses the yyyy-MM-dd HH:mm:ss format but yes, having all timestamps in a consistent format and time zone is useful for log comparisons. 

I'd second the global dcmd flag suggestion which would allow the option of the timestamp(on or off). Some commands should have timestamp on by default though. Those where output is sensitive to the time that the command was issued. e.g. 
Thread dumps
...and as per JBS suggestions, other examples include: (but not limited to)
GC.finalizer_info
GC.heap_info

Looking at such data output in isolation with the absence of timestamps makes it far less valuable IMO, especially when one wants to compare it to application logs, GC logs etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3318375894

From kevinw at openjdk.org  Mon Sep 22 11:53:31 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 22 Sep 2025 11:53:31 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <62myjO2d32Qn7JlSXzrPnBQTLDKQ47iuCLGDJ3kdN5Y=.baaca9de-baec-4bd9-9a6b-5e86e1910cce@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

I think it should be clearer what the benefit is, who the users are.

In a remote support situation where the the user is gathering info, then timestamps are good.
Running "date; jcmd ... " is an alternative.


An optional global timestamp setting could be in the Jcmd launcher, which would mean it doesn't have to be implemented in each native diagnostic command impl.
i.e. a jcmd option before the PID.

jcmd -T PID command...  (or whatever option)
jcmd -T -f commands.txt  ... could that print a timestamp before every inidvidual command?

That might be straightforward, but then you can get double timestamps if the jcmd implementation already prints one (so do you remove the timestamp from Thread.print if the jcmd launcher starts printing it?)

Also complicated for some to commands enable a timestamp by default, the jcmd launcher does not know anything about command implementations.
So maybe it needs some common code on the native side.

Do we print a timestamp if the command is not recognised?

Lots of questions. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3318507194

From mli at openjdk.org  Mon Sep 22 12:32:06 2025
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 22 Sep 2025 12:32:06 GMT
Subject: RFR: 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()
In-Reply-To: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
References: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
Message-ID: <tXvk4Xyw1Wn5DfiyFU5_Ae3AcseN0LYIehdmaom_vR0=.856ad4f5-822a-47f4-8b4b-8ccf9961209c@github.com>

On Sun, 21 Sep 2025 10:52:28 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> We can clean up the duplicate call to ext_Zicboz.enable_feature() in VM_Version::rivos_features(), as it is already invoked at https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L286

Hey, Thanks for the cleanup.
Can you drop this pr? we'll cleanup it up finally together after we verify the extensions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27409#issuecomment-3318720143

From stefank at openjdk.org  Mon Sep 22 13:45:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Sep 2025 13:45:46 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v9]
In-Reply-To: <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
 <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com>
Message-ID: <79md5e7_bxwUB16s9pd2iVsLr_mtAgh9bF8ezYApq0g=.284a9a47-3b25-4d88-bf75-df0a259849d5@github.com>

On Sat, 20 Sep 2025 07:21:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> But other reviewers are okay with this and I don't want to hold up this change.

We don't have to rush this is. Is your suggestion that we should use a typedef? (I think the _t suffix is reserved by POSIX and should probably not be used here).

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3319127386

From jpai at openjdk.org  Mon Sep 22 13:47:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 Sep 2025 13:47:25 GMT
Subject: RFR: 8367598: Switch to CRC32C for SEED calculation in
 jdk.test.lib.Utils
Message-ID: <jT_tMPKjF3lB9dr6b3j_4a7J2G3LFdSIB9HRQywv6EU=.fb355792-ebbe-43b6-9dd9-9897edbf1a24@github.com>

Can I please get a review of this change to a test library class which proposes to remove the calls to `MessageDigest` from the static initializer of `jdk.test.lib.Utils`?

The `Utils` test library class constructs a random generator which can be used in tests. Back in JDK 16, we updated this class to use a consistent seed (if none is explicitly set) when running against promotable JDK builds. This was done in https://bugs.openjdk.org/browse/JDK-8253750. The motivation behind using a consistent seed as explained in that issue is reasonable.

In the implementation of seed generation, we generate the seed based off the JDK build version and we currently use the `java.security.MessageDigest` class to generate the bytes for the seed. The use of `MessageDigest` here drags in a lot of security-libs infrastructure. If this `Utils` class then gets used in tests that configure the security-libs in a specific manner (like intentionally setting certain configurations which trigger an exception), then the `Utils` class fails during its static initialization. This prevents its usage in such tests as well as sometimes causes unexpected failures like:

https://bugs.openjdk.org/browse/JDK-8367583
https://bugs.openjdk.org/browse/JDK-8345578

The change in this PR replaces the usage of security-libs infrastructure with a much more simpler implementation for the seed generation. The proposed usage of `CRC32`, to generate the seed based off the version, doesn't drag in these additional classes and should thus prevent issues like the ones noted above.

I've run this change locally as well as our CI (tier1, tier2, tier3) and haven't seen any failures.

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

Commit messages:
 - 8367598: Switch to CRC32C for SEED calculation in jdk.test.lib.Utils

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

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

From stuefe at openjdk.org  Mon Sep 22 13:59:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 22 Sep 2025 13:59:18 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v9]
In-Reply-To: <79md5e7_bxwUB16s9pd2iVsLr_mtAgh9bF8ezYApq0g=.284a9a47-3b25-4d88-bf75-df0a259849d5@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
 <Lt-pu-SaexXFMP8U-AIgRJMpIy5uilWC5vBgStedZk4=.7f9d265b-5a9a-4fbf-81fc-044c19914026@github.com>
 <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com>
 <79md5e7_bxwUB16s9pd2iVsLr_mtAgh9bF8ezYApq0g=.284a9a47-3b25-4d88-bf75-df0a259849d5@github.com>
Message-ID: <ItBWHO-wrjMCYtj_MM8bGPkOedV_kifb-Ee-99JwJ-0=.772e76f1-010f-45fa-ae0c-f92678bf910b@github.com>

On Mon, 22 Sep 2025 13:42:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > But other reviewers are okay with this and I don't want to hold up this change.
> 
> We don't have to rush this is. Is your suggestion that we should use a typedef? (I think the _t suffix is reserved by POSIX and should probably not be used here).

If others agree, since I am not alone, and these are matters of taste mostly. It's not a hill I would die on, and I understand if you all like to be done with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3319202044

From asmehra at openjdk.org  Mon Sep 22 19:45:31 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 22 Sep 2025 19:45:31 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <FDh2eVgDsyOYb-zrDTisyAUEeR-Wsa5lT4uIcnycOSU=.f8284b93-6667-4c67-8b46-5aef70eb064d@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

src/hotspot/share/cds/aotClassInitializer.cpp line 53:

> 51: 
> 52:   if (!ik->is_initialized() && !ik->is_being_initialized()) {
> 53:     if (ik->has_aot_safe_initializer()) {

Now that we are forcing initialization of classes annotated with `AOTSafeClassInitializer`, is it still possible that a class is not initialized but `has_aot_safe_initializer()` is true?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2370086101

From schernyshev at openjdk.org  Mon Sep 22 20:06:10 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 22 Sep 2025 20:06:10 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <yMfh1521iPYCjmqE1C4piYJw3RA_pC6TBRISWjSKGeA=.45f87bac-d7b4-42b9-b844-d56ccfa4c8b4@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

@turbanoff @dholmes-ora @larry-cable Could you please take a look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3321272195

From iklam at openjdk.org  Mon Sep 22 21:21:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 22 Sep 2025 21:21:29 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <FDh2eVgDsyOYb-zrDTisyAUEeR-Wsa5lT4uIcnycOSU=.f8284b93-6667-4c67-8b46-5aef70eb064d@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
 <FDh2eVgDsyOYb-zrDTisyAUEeR-Wsa5lT4uIcnycOSU=.f8284b93-6667-4c67-8b46-5aef70eb064d@github.com>
Message-ID: <l4KlDwG2TyUMAX32QPYI1ZsuqGD5cAm8yEdDINx8sxQ=.bd80b700-fc24-49cc-89a8-179993915907@github.com>

On Mon, 22 Sep 2025 19:42:39 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
>> 
>> ### Background:
>> 
>> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
>> 
>> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
>> 
>> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
>> 
>> ### Problem:
>> 
>> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
>> 
>> ### Fix:
>> 
>> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
>> 
>> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.
>
> src/hotspot/share/cds/aotClassInitializer.cpp line 53:
> 
>> 51: 
>> 52:   if (!ik->is_initialized() && !ik->is_being_initialized()) {
>> 53:     if (ik->has_aot_safe_initializer()) {
> 
> Now that we are forcing initialization of classes annotated with `AOTSafeClassInitializer`, is it still possible that a class is not initialized but `has_aot_safe_initializer()` is true?

It's possible in some rare circumstances. I.e, in the assembly phase, we take a path that was not cover in the training run (e.g. some sort of advanced JLI linkage). We could load a class X without initializing it. This could happen if X is used only for instanceof checking, or if it was loaded during verification of other classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2370329695

From duke at openjdk.org  Mon Sep 22 22:55:44 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 22 Sep 2025 22:55:44 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <TdAgdLQPEVK9Hbb9FwgmP1pheoSDioo-imSFUjHw_s4=.55f6b833-b64d-426f-961f-256037c75e82@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

will do!

On 9/22/25 1:04 PM, Sergey Chernyshev wrote:
> *sercher* left a comment (openjdk/jdk#25824) 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$>
>
> @turbanoff 
> <https://urldefense.com/v3/__https://github.com/turbanoff__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2812g3XS-WA$> 
> @dholmes-ora 
> <https://urldefense.com/v3/__https://github.com/dholmes-ora__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2813-Ly68vg$> 
> @larry-cable 
> <https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810J2TUJ4w$> 
> Could you please take a look at this?
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VRW3666Z2O5P7IMJT3UBI3LAVCNFSM6AAAAAB7MZH7WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRRGI3TEMJZGU__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810UmUzuKQ$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------clQK6hO50V7lxYIyzZn4ddE5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    will do!<br>
    <br>
    <div class="moz-cite-prefix">On 9/22/25 1:04 PM, Sergey Chernyshev
      wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/6394632?s=20&amp;v=4" moz-do-not-send="true"><strong>sercher</strong> left a comment <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$" moz-do-not-send="true">(openjdk/jdk#25824)</a></div>
      <p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/turbanoff/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/turbanoff__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2812g3XS-WA$" ***@***.***</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/dholmes-ora/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/dholmes-ora__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2813-Ly68vg$" ***@***.***</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense
 .com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810J2TUJ4w$" ***@***.***</a> Could you please take
        a look at this?</p>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/25824*issuecomment-3321272195__;Iw!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810uaE86kA$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VRW3666Z2O5P7IMJT3UBI3LAVCNFSM6AAAAAB7MZH7WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRRGI3TEMJZGU__;!!ACWV5N9M2RV99hQ!P9dALpheoPUoaoWeQ1rj6dzwU42yVWWmfrsbZt429ot-cdhEW8CspQyFVJ455ZjgbI2QssgWZS26ouu2810UmUzuKQ$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67RY5B2DW4ALWX3PHZ33UBI3LA5CNFSM6AAAAAB7MZH7WGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWF62LYG.gif" height="1" width="1" alt="" moz-do-not-send="true"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/25824/c3321272195</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/25824#issuecomment-3321272195",
"url": "https://github.com/openjdk/jdk/pull/25824#issuecomment-3321272195",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------clQK6hO50V7lxYIyzZn4ddE5--

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3321771506

From liach at openjdk.org  Mon Sep 22 23:40:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Sep 2025 23:40:50 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <1ZQQzDNnT-fjd_9RUXuI4HYnCgOz16m1Xmqoc1wPXRE=.4f7435f9-51cc-4639-add5-fdc449c98015@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

Looks good otherwise.

src/java.base/share/classes/java/lang/Object.java line 1:

> 1: /*

Redundant change

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

PR Review: https://git.openjdk.org/jdk/pull/27402#pullrequestreview-3255597318
PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2370646998

From dholmes at openjdk.org  Tue Sep 23 02:51:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 02:51:37 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

This seems reasonable but I am far from expert in this area of macOS, nor in the Java side of this code. Serviceability need to take a good look at this.

I few minor nits below.

Thanks

src/hotspot/os/bsd/os_bsd.cpp line 893:

> 891: //
> 892: static const char VAR_FOLDERS[] = "/var/folders/";
> 893: int os::Bsd::get_user_tmp_dir_macos(const char* user, int vmid, char *output_path, int output_size /* = PATH_MAX */) {

Suggestion:

int os::Bsd::get_user_tmp_dir_macos(const char* user, int vmid, char* output_path, int output_size) {

src/hotspot/os/bsd/os_bsd.cpp line 912:

> 910:       // absolute path to the bucket
> 911:       char bucket[PATH_MAX];
> 912:       int b = snprintf(bucket, PATH_MAX, "%s%s/", VAR_FOLDERS, bucket_de->d_name);

Suggestion:

      int b = os::snprintf(bucket, PATH_MAX, "%s%s/", VAR_FOLDERS, bucket_de->d_name);

Just for clarity

src/hotspot/os/bsd/os_bsd.cpp line 936:

> 934:         //
> 935:         char perfdata_path[PATH_MAX];
> 936:         int p = snprintf(perfdata_path, PATH_MAX, "%s%s/T/%s_%s/", bucket, subbucket_de->d_name, PERFDATA_NAME, user);

Suggestion:

        int p = os::snprintf(perfdata_path, PATH_MAX, "%s%s/T/%s_%s/", bucket, subbucket_de->d_name, PERFDATA_NAME, user);

src/hotspot/os/bsd/os_bsd.cpp line 947:

> 945: 
> 946:           // the return value of snprintf is not checked for the second time
> 947:           return snprintf(output_path, output_size, "%s%s/T", bucket, subbucket_de->d_name);

Suggestion:

          return os::snprintf(output_path, output_size, "%s%s/T", bucket, subbucket_de->d_name);

src/hotspot/os/bsd/os_bsd.hpp line 68:

> 66: 
> 67: #ifdef __APPLE__
> 68:   static int get_user_tmp_dir_macos(const char* user, int vmid, char *output_buffer, int buffer_size /* = PATH_MAX */);

Suggestion:

  static int get_user_tmp_dir_macos(const char* user, int vmid, char* output_buffer, int buffer_size);

The buffer size is up to the caller.

src/hotspot/os/posix/perfMemory_posix.cpp line 1180:

> 1178:   int nspid = LINUX_ONLY(os::Linux::get_namespace_pid(vmid)) NOT_LINUX(-1);
> 1179:   const char* luser = NOT_MACOS(get_user_name(vmid, &nspid, CHECK))
> 1180:     MACOS_ONLY(get_user_name(os::Bsd::get_process_uid(vmid)));

Suggestion:

  const char* luser = NOT_MACOS(get_user_name(vmid, &nspid, CHECK))
                      MACOS_ONLY(get_user_name(os::Bsd::get_process_uid(vmid)));

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 31:

> 29: import com.sun.tools.attach.spi.AttachProvider;
> 30: 
> 31: import sun.jvmstat.PlatformSupport;

This is convenient but I'm not sure it is appropriate. Need the serviceability folk to comment.

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:

> 47:     // the latter can be changed by the user.
> 48:     // Any changes to this needs to be synchronized with HotSpot.
> 49:     private static final String tmpdir;

So we can't cache this any more?

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

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3255835341
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370839037
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370840143
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370841710
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370842039
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370844530
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370846681
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370851193
PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2370853656

From iklam at openjdk.org  Tue Sep 23 04:16:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 04:16:21 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
In-Reply-To: <eRSgNCnt2_GrAGGhFNcx0aQsbygiI1fI-UZ3KNQXxMY=.fdba5c6e-c231-4b7a-8f06-197c1610b1c8@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <eRSgNCnt2_GrAGGhFNcx0aQsbygiI1fI-UZ3KNQXxMY=.fdba5c6e-c231-4b7a-8f06-197c1610b1c8@github.com>
Message-ID: <V2HGym3lEWcQllWrxNhUSSxTfjqwUcngBwo48SpkODk=.2edf6741-4f78-4cb1-a6ba-f6af7577a4f0@github.com>

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

> So where were these JNI defined classes originating from when you saw the failures?

We found this bug with an internal test case that uses a JNI library.

> src/hotspot/share/classfile/classLoader.cpp line 1196:
> 
>> 1194:   if (src == nullptr) {
>> 1195:     if (loader == nullptr) {
>> 1196:       // JFR classes
> 
> What was this referring to? I traced this back to "8186842: Use Java class loaders for creating the CDS archive" but no mention of any JFR classes was made. FWIW I can't see any use of JNI DefineClass in the JDK code, so this change would only affect end-user code.

JFR doesn't call JNI DefineClass. Instead, it uses `ClassFileStream` and `ClassFileParser` directly, so it can accomplish the same thing (defining a class with a NULL code source).

The above was written when JFR was defining classes with a with a NULL code source:

https://github.com/openjdk/jdk/blob/02f895c5f6f6de38549337d45ed8ba4c446e9677/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp#L1165

JFR has since been updated to pass a non-null code source to `ClassFileStream`, so the comment about JFR classes is no longer valid.

> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JNIDefineClass.java line 134:
> 
>> 132: }
>> 133: 
>> 134: // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,
> 
> Suggestion:
> 
> // This class is loaded into the bootstrap loader using JNI_DefineClass() with a null code source,
> 
> Suggestion:
> 
> // This class is loaded into the bootstrap loader using JNI_DEfineClass() with a null code source,

I changed to `JNI DefineClass`, as we don't actually have a C++ symbol of `JNI_DefineClass`.

> test/hotspot/jtreg/runtime/cds/appcds/aotCache/libJNIDefineClassApp.c line 34:
> 
>> 32:     jclass returnValue = (*env)->DefineClass(env, classNameChar, classLoader, arrayContent, bytecodeLength);
>> 33:     (*env)->ReleaseByteArrayElements(env, bytecode, arrayContent, JNI_ABORT);
>> 34:     (*env)->ReleaseStringUTFChars(env, className, classNameChar);
> 
> Does this pass `-Xcheck:jni`? ie. do you need to check for exceptions in the above sequence.

I copied the code from here. Is this style OK for jtreg tests?

https://github.com/openjdk/jdk/blob/61c5245bf7d6626b0c816612adcb0d94d6863644/test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp#L44-L52

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

PR Comment: https://git.openjdk.org/jdk/pull/27412#issuecomment-3322349826
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371075678
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371075738
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371075953

From dholmes at openjdk.org  Tue Sep 23 06:35:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 06:35:35 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
In-Reply-To: <V2HGym3lEWcQllWrxNhUSSxTfjqwUcngBwo48SpkODk=.2edf6741-4f78-4cb1-a6ba-f6af7577a4f0@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <eRSgNCnt2_GrAGGhFNcx0aQsbygiI1fI-UZ3KNQXxMY=.fdba5c6e-c231-4b7a-8f06-197c1610b1c8@github.com>
 <V2HGym3lEWcQllWrxNhUSSxTfjqwUcngBwo48SpkODk=.2edf6741-4f78-4cb1-a6ba-f6af7577a4f0@github.com>
Message-ID: <hOz9g-oc9IL0DAV7tcnK0J1Z7TUfBLEjGTOOItBEUT4=.52b10234-a365-4534-bf1e-e6d5e855af4d@github.com>

On Tue, 23 Sep 2025 04:12:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoader.cpp line 1196:
>> 
>>> 1194:   if (src == nullptr) {
>>> 1195:     if (loader == nullptr) {
>>> 1196:       // JFR classes
>> 
>> What was this referring to? I traced this back to "8186842: Use Java class loaders for creating the CDS archive" but no mention of any JFR classes was made. FWIW I can't see any use of JNI DefineClass in the JDK code, so this change would only affect end-user code.
>
> JFR doesn't call JNI DefineClass. Instead, it uses `ClassFileStream` and `ClassFileParser` directly, so it can accomplish the same thing (defining a class with a NULL code source).
> 
> The above was written when JFR was defining classes with a with a NULL code source:
> 
> https://github.com/openjdk/jdk/blob/02f895c5f6f6de38549337d45ed8ba4c446e9677/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp#L1165
> 
> JFR has since been updated to pass a non-null code source to `ClassFileStream`, so the comment about JFR classes is no longer valid.

Thanks for clarifying.

>> test/hotspot/jtreg/runtime/cds/appcds/aotCache/libJNIDefineClassApp.c line 34:
>> 
>>> 32:     jclass returnValue = (*env)->DefineClass(env, classNameChar, classLoader, arrayContent, bytecodeLength);
>>> 33:     (*env)->ReleaseByteArrayElements(env, bytecode, arrayContent, JNI_ABORT);
>>> 34:     (*env)->ReleaseStringUTFChars(env, className, classNameChar);
>> 
>> Does this pass `-Xcheck:jni`? ie. do you need to check for exceptions in the above sequence.
>
> I copied the code from here. Is this style OK for jtreg tests?
> 
> https://github.com/openjdk/jdk/blob/61c5245bf7d6626b0c816612adcb0d94d6863644/test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp#L44-L52

I don't know if that one passes `-Xcheck:jni` either (I think we only run runtime tests with `-Xcheck:jni`), so please check else it may fail in tier4. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371294521
PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371297714

From dholmes at openjdk.org  Tue Sep 23 06:41:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 06:41:32 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
In-Reply-To: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
Message-ID: <clDorkwjc-jWt_GNucsHej1SdDrFA6BT66Q8px3F_V4=.9cd14708-9a8e-4908-b1c7-c06990b7ae0a@github.com>

On Sun, 21 Sep 2025 20:00:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
> 
> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
> 
> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
> 
> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

src/hotspot/share/cds/lambdaFormInvokers.cpp line 203:

> 201:       char *buf = NEW_RESOURCE_ARRAY(char, len);
> 202:       memcpy(buf, (char*)h_bytes->byte_at_addr(0), len);
> 203:       ClassFileStream st((u1*)buf, len, "jrt:/java.base");

Are lambdaForms only ever from java.base?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2371307950

From dzhang at openjdk.org  Tue Sep 23 06:51:31 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 23 Sep 2025 06:51:31 GMT
Subject: RFR: 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()
In-Reply-To: <tXvk4Xyw1Wn5DfiyFU5_Ae3AcseN0LYIehdmaom_vR0=.856ad4f5-822a-47f4-8b4b-8ccf9961209c@github.com>
References: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
 <tXvk4Xyw1Wn5DfiyFU5_Ae3AcseN0LYIehdmaom_vR0=.856ad4f5-822a-47f4-8b4b-8ccf9961209c@github.com>
Message-ID: <4W-Tncv4nrPZkhOy-s8PIX5hGByYXMrKHfJXGtA9QBw=.b6db6695-0890-4564-95ba-b173014d5e7b@github.com>

On Mon, 22 Sep 2025 12:29:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hey, Thanks for the cleanup. Can you drop this pr? we'll cleanup it up finally together after we verify the extensions.

@Hamlin-Li Sure! Do I need to assign the issue to you?

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

PR Comment: https://git.openjdk.org/jdk/pull/27409#issuecomment-3322644130

From duke at openjdk.org  Tue Sep 23 09:00:13 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Tue, 23 Sep 2025 09:00:13 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <UhtkOWgYWt4oM9gHx9by0OcEeCCeuRTBuo6Kn7HJHK0=.a9c34983-6a0f-49b5-8316-249ce421164c@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Speaking of having "print a timestamp" as a global flag. Placing be the flag early for the launcher, before `pid | main class` gives some benefits:
* we can document the flag in the general documentation "jcmd -h"
* we could place the timestamp on the same line with PID printed by launcher.

$ jcmd -T ${PID} VM.info
12345: 2025-01-01 23:59:59
. . .

Is there any issues to that?

On the other hand, I see dcmd implements a special rule to handle "-h", "-help", and "--help" flags placed at the end of `jcmd` arguments list. We could allow the new "timestamp" flag to be passed past the `jcmd PID command`, Process the flag in `DCmdFactory` and pass the boolean down to a concrete `DCmd` instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323026694

From kevinw at openjdk.org  Tue Sep 23 09:48:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 23 Sep 2025 09:48:25 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <tid__B3lWtwKY09Rd01S0KeK_wxzkI81C3TFjvh0HwQ=.e8710c78-2ba3-4f34-946a-0e203a5def40@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Hi, that sounds promising.  
I do think we should state the benefit of having this (we don't expect much latency as this is a local attach).

Passing something on to the native impl is interesting - then, if the jcmd launcher prints pid:, then timestamp on a newline, can Thread.print find out a timestamp is already printed, and not duplicate it?

3975026:
2025-09-23 10:31:54
Full thread dump ...

Or, should Thread.print stop printing a timestamp, and rely on the launcher to do it.  That would avoid that communication, but would mean we have to default to timestamps ON, or Thread.print output format will change (which is not completely illegal, but will no doubt surprise some people/scripts).  Or, have the two sides communicate and Thread.print prints the timestamp, if it has not been shown already.  Nothing there is as simple as we'd like. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323188843

From alanb at openjdk.org  Tue Sep 23 09:51:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Sep 2025 09:51:32 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <8duI9y23ZbCVBCnXhbXHm5FHbLzQCXoQr_4f2zhzJic=.154c446d-c3fb-4a32-a88f-0ef0dd76fedf@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

It might be useful for @larry-cable to comment on this too. I think he's exploring some of these command serving up JSON rather than plain text. Any "infrastructure" that print a plain text timestamp could mess that up.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323199390

From stuefe at openjdk.org  Tue Sep 23 09:59:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Sep 2025 09:59:53 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <oM68Gs7U2PdAcJJYitPXlYAALeULpk6Rx5U2uZx54yA=.e372d960-07b3-498a-89d3-14bfc655f3c6@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

Piling on...

I think this feature would be useful. I wished for this more often than not.

I think the printing should be done on the server side, not on the client side (be it a `date` before the invocation of jcmd, or jcmd itself printing the date), since the timestamp on the server side may be different than that of the client jcmd.

I would prefer a timestamp in the UL "time" decoration format: Full ISO-8601, including timezone offset. See https://openjdk.org/jeps/158 . That would also keep in line with gc logs etc.

I am not sure we need a specific option to disable or enable this. Who would want to disable this feature?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3323234159

From asmehra at openjdk.org  Tue Sep 23 14:06:31 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 23 Sep 2025 14:06:31 GMT
Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer
 classes
In-Reply-To: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
References: <RXBXw_G8qTmGyTJ3weiA64U6coud67uEOADLGbHZDCE=.907e65ca-3617-4217-880c-f2da397b51e4@github.com>
Message-ID: <TQ4IoIXiBZC4HaWiQvJ4wevdXP9aD8AVMv-v1CyIocE=.bcef285c-a749-4eaf-a935-9c579a8e5a99@github.com>

On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion.
> 
> ### Background:
> 
> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites.
> 
> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase.
> 
> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::<clinit>` will not be executed, and the static variables of `X` will be available upon JVM bootstrap.
> 
> ### Problem:
> 
> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::<clinit>` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized.
> 
> ### Fix:
> 
> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state.
> 
> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs.

lgtm

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

Marked as reviewed by asmehra (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27402#pullrequestreview-3258197018

From iklam at openjdk.org  Tue Sep 23 16:58:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 16:58:32 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v2]
In-Reply-To: <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
Message-ID: <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>

On Thu, 18 Sep 2025 12:48:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove calculate_header_size

Hi Hamlin, thanks for doing the clean up. I have some suggestions to for the comments, and some further code changes to improve readability.

src/hotspot/share/classfile/compactHashtable.hpp line 166:

> 164: // with the type in the left-most 2-bit and offset in the remaining 30-bit.
> 165: // The last entry is a special type. It contains the end of the last
> 166: // bucket.

These two lines should be deleted.

src/hotspot/share/classfile/compactHashtable.hpp line 170:

> 168: // There are three types of buckets, regular buckets and value_only buckets and table_end
> 169: // bucket. The value_only buckets have '01' in their highest 2-bit, and regular buckets have
> 170: // '00' in their highest 2-bit, and table_end bucket has '11' in its highest 2-bit.

Suggestion:

// There are three types of buckets: regular, value_only, and table_end.
// The regular buckets have '00' in their highest 2-bit.
// The value_only buckets have '01' in their highest 2-bit.
// There is only a single table_end bucket that marks the end of buckets[]. It has '11' in its highest 2-bit.

src/hotspot/share/classfile/compactHashtable.hpp line 174:

> 172: // For regular buckets, each entry is 8 bytes in the entries[]:
> 173: //   u4 hash;    // entry hash
> 174: //   u4 value;   // it could be offset or index or any payload.

I think `value` is confusing, as it's not the same as the template type `V`. I would suggest changing the declaration to 


class CompactHashtableWriter: public StackObj {
public:
  class Entry {
    unsigned int _hash;
-   u4 _value;
+   u4 _encoded_value;


All parameters of `offset` should be changed to `encoded_value`.

This comment should be updated:


u4 encoded_value; // A 32-bit encoding of the template type V. The template parameter DECODE
                  // converts this to type V. Many CompactHashtables encode a pointer as a 32-bit offset, where
                  //   V entry = (V)(base_address + offset)
                  // see StringTable, SymbolTable and AdapterHandlerLibrary for examples

 
I think we should consider a future clean up of adding an `ENCODE` template parameter so that the various table dumping functions can be consolidated.

src/hotspot/share/classfile/compactHashtable.hpp line 178:

> 176: //               //   YourEntryType* entry = (YourEntryType*)(base_address + offset)
> 177: //               // check StringTable, SymbolTable and AdapterHandlerLibrary for its usage examples.
> 178: // A regular bucket could also contains zero entry for empty bucket.

The line "// A regular bucket could also contains zero entry for empty bucket" should be deleted, replaced with explanation below.

src/hotspot/share/classfile/compactHashtable.hpp line 182:

> 180: // For value_only buckets, each entry has only the 4-byte 'value' in the entries[].
> 181: //
> 182: // For table_end bucket, there is no corresponding entry, i.e. it always contains zero entry.

Suggestion:

// The single table_end bucket has no corresponding entry.

src/hotspot/share/classfile/compactHashtable.hpp line 193:

> 191: //         |  +----+ +----+                 |
> 192: //         v       v v                      v
> 193: // entries[H,O,H,O,O,H,O,H,O.................]

Suggestion:

// The number of entries in bucket <i> can be calculated like this:
//      my_offset   = _buckets[i]   & 0x3fffffff; // mask off top 2-bit
//      next_offset = _buckets[i+1] & 0x3fffffff
//  For REGULAR_BUCKET_TYPE
//      num_entries = (next_offset - my_offset) / 8;
//  For VALUE_ONLY_BUCKET_TYPE
//      num_entries = (next_offset - my_offset) / 4;
//
// If bucket <i> is empty, we have my_offset == next_offset. Empty buckets are
// always encoded as regular buckets.
//
// In the following example:
//   - The 0-th bucket is a REGULAR_BUCKET_TYPE with two entries
//   - The 1-st bucket is a VALUE_ONLY_BUCKET_TYPE with one entry.
//   - The 2-th bucket is a REGULAR_BUCKET_TYPE with zeo entries.
//
// buckets[0, 4, 5(empty), 5, ...., N(table_end)]
//         |  |  |         |        |
//         |  |  +---+-----+        |
//         |  |      |              |
//         |  +----+ +              |
//         v       v v              v
// entries[H,O,H,O,O,H,O,H,O........]

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27360#pullrequestreview-3258735478
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372852733
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372825872
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372931360
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372866326
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372831444
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2372902511

From schernyshev at openjdk.org  Tue Sep 23 17:03:46 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 23 Sep 2025 17:03:46 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <gjyA1t_guxP2Za_WS3cDjFlRAeDexPyq-eE3487wMWk=.42fcb060-4750-4ac9-ba2b-1822908c4fb2@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/779a1b35..de855d37

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

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

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

From schernyshev at openjdk.org  Tue Sep 23 17:03:48 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 23 Sep 2025 17:03:48 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
Message-ID: <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>

On Tue, 23 Sep 2025 02:43:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:
> 
>> 47:     // the latter can be changed by the user.
>> 48:     // Any changes to this needs to be synchronized with HotSpot.
>> 49:     private static final String tmpdir;
> 
> So we can't cache this any more?

Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2372940682

From mli at openjdk.org  Tue Sep 23 17:51:07 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 17:51:07 GMT
Subject: RFR: 8368180: RISC-V: Remove redundant ext_Zicboz.enable_feature()
In-Reply-To: <4W-Tncv4nrPZkhOy-s8PIX5hGByYXMrKHfJXGtA9QBw=.b6db6695-0890-4564-95ba-b173014d5e7b@github.com>
References: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
 <tXvk4Xyw1Wn5DfiyFU5_Ae3AcseN0LYIehdmaom_vR0=.856ad4f5-822a-47f4-8b4b-8ccf9961209c@github.com>
 <4W-Tncv4nrPZkhOy-s8PIX5hGByYXMrKHfJXGtA9QBw=.b6db6695-0890-4564-95ba-b173014d5e7b@github.com>
Message-ID: <re88oqhcV3cIY8LLGdn1eQ82amNbszdgM9wR9z710EU=.be5110b3-e2d5-4b5d-86fe-a7906f5d8a30@github.com>

On Tue, 23 Sep 2025 06:48:40 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hey, Thanks for the cleanup.
>> Can you drop this pr? we'll cleanup it up finally together after we verify the extensions.
>
>> Hey, Thanks for the cleanup. Can you drop this pr? we'll cleanup it up finally together after we verify the extensions.
> 
> @Hamlin-Li Sure! Do I need to assign the issue to you?

@DingliZhang It's fine, you can just close it. I'll go through all the extensions altogether when I work on it. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27409#issuecomment-3324988611

From mli at openjdk.org  Tue Sep 23 18:20:06 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 18:20:06 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v3]
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <Gqfzd88W63aZhpfIR4paHXAaMxgbH6fDqkVEMd9yClc=.9bd324cb-4bb7-44c6-a9d4-d9f3b81356db@github.com>

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  refine comments; rename from _value to _encoded_value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27360/files
  - new: https://git.openjdk.org/jdk/pull/27360/files/176fdc67..9d3ad1ec

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

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

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

From mli at openjdk.org  Tue Sep 23 18:25:35 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 18:25:35 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v2]
In-Reply-To: <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
 <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
Message-ID: <ZsOyvFiGG7my4Tcl0w6mH7KmP6J_nMd54Ea7QjVpRMs=.8bf182bd-ab29-43ca-b634-7fd0f08591d7@github.com>

On Tue, 23 Sep 2025 16:55:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi Hamlin, thanks for doing the clean up. I have some suggestions to for the comments, and some further code changes to improve readability.

Thank you @iklam for helping to refine the commets. I took all your suggestions, except of one, please check my reply above.

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

PR Comment: https://git.openjdk.org/jdk/pull/27360#issuecomment-3325092739

From mli at openjdk.org  Tue Sep 23 18:35:09 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 18:35:09 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v2]
In-Reply-To: <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
 <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
Message-ID: <Vap8PipGmhK9Hq-_w1hJ7K_l86rd_8ivdbcZfM2JhAM=.585e152a-cb94-4375-a0a6-262b2d487d60@github.com>

On Tue, 23 Sep 2025 16:53:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> All parameters of offset should be changed to encoded_value.

I guess you mean change from `value` to encoded_value in `CompactHashtable`?
I did not touch the parameter name `offset` in read_value_from_compact_hashtable (which is used in OffsetCompactHashtable), as I think it means `offset` intentionally.
But please correct me if I'm understanding wrongly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2373145523

From mli at openjdk.org  Tue Sep 23 19:01:49 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 19:01:49 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v4]
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <7Uuat45VgibB-QxDNYfLawOn5wQY0JWiMgJJ_b3nfQk=.a30550db-d9db-4be8-9cc6-28e1b6ea0e07@github.com>

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27360/files
  - new: https://git.openjdk.org/jdk/pull/27360/files/9d3ad1ec..e90142f6

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

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

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

From mli at openjdk.org  Tue Sep 23 19:01:52 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 23 Sep 2025 19:01:52 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v2]
In-Reply-To: <Vap8PipGmhK9Hq-_w1hJ7K_l86rd_8ivdbcZfM2JhAM=.585e152a-cb94-4375-a0a6-262b2d487d60@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
 <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
 <Vap8PipGmhK9Hq-_w1hJ7K_l86rd_8ivdbcZfM2JhAM=.585e152a-cb94-4375-a0a6-262b2d487d60@github.com>
Message-ID: <uIH6nthWb871DG-iNL4kAR7LtM_6r5-ULb8265lyS0w=.1780acae-a22a-4bc8-aef5-e287de05f718@github.com>

On Tue, 23 Sep 2025 18:32:15 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/classfile/compactHashtable.hpp line 174:
>> 
>>> 172: // For regular buckets, each entry is 8 bytes in the entries[]:
>>> 173: //   u4 hash;    // entry hash
>>> 174: //   u4 value;   // it could be offset or index or any payload.
>> 
>> I think `value` is confusing, as it's not the same as the template type `V`. I would suggest changing the declaration to 
>> 
>> 
>> class CompactHashtableWriter: public StackObj {
>> public:
>>   class Entry {
>>     unsigned int _hash;
>> -   u4 _value;
>> +   u4 _encoded_value;
>> 
>> 
>> All parameters of `offset` should be changed to `encoded_value`.
>> 
>> This comment should be updated:
>> 
>> 
>> u4 encoded_value; // A 32-bit encoding of the template type V. The template parameter DECODE
>>                   // converts this to type V. Many CompactHashtables encode a pointer as a 32-bit offset, where
>>                   //   V entry = (V)(base_address + offset)
>>                   // see StringTable, SymbolTable and AdapterHandlerLibrary for examples
>> 
>>  
>> I think we should consider a future clean up of adding an `ENCODE` template parameter so that the various table dumping functions can be consolidated.
>
>> All parameters of offset should be changed to encoded_value.
> 
> I guess you mean change from `value` to encoded_value in `CompactHashtable`?
> I did not touch the parameter name `offset` in read_value_from_compact_hashtable (which is used in OffsetCompactHashtable), as I think it means `offset` intentionally.
> But please correct me if I'm understanding wrongly.

Modify from `offset`/`value` to `encoded_value` in CompactHashtable template parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2373201842

From amenkov at openjdk.org  Tue Sep 23 20:28:59 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Sep 2025 20:28:59 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock information to
 Thread.dump_to_file
Message-ID: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>

The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.

Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/27457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365057
  Stats: 69 lines in 6 files changed: 63 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

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

From duke at openjdk.org  Tue Sep 23 21:26:00 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 23 Sep 2025 21:26:00 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: <-qtIjh72_GAo1imT-FMFG4JZY8oBQQZk1OIzXEk46xM=.615a0f83-00dd-49b3-9272-6f61df419d51@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.

Withdrawn in favor of using _is_shutting down introduced by 8366865

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

PR Comment: https://git.openjdk.org/jdk/pull/27115#issuecomment-3325595230

From duke at openjdk.org  Tue Sep 23 21:26:00 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 23 Sep 2025 21:26:00 GMT
Subject: Withdrawn: 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: <nVL6lWMBbvdIo0GbcvoSnR-_q4yijX_xWzOPoxJXq_M=.873299a3-0702-4960-8608-8f412917f943@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.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Tue Sep 23 21:34:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 21:34:27 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v2]
In-Reply-To: <uIH6nthWb871DG-iNL4kAR7LtM_6r5-ULb8265lyS0w=.1780acae-a22a-4bc8-aef5-e287de05f718@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <vmbNWIHJJd_1LQQxBMrYJq5KP37R0wXeqLohLhaNS2U=.c5175eed-54fb-4787-a8fa-cb208f5ab2a9@github.com>
 <hbG-GKhAyWLfo0c6SF6qKKOxC5A-xT4sTT4Ms3WnIRA=.83c7d8c0-2b05-4ad0-be2a-10854295e939@github.com>
 <Vap8PipGmhK9Hq-_w1hJ7K_l86rd_8ivdbcZfM2JhAM=.585e152a-cb94-4375-a0a6-262b2d487d60@github.com>
 <uIH6nthWb871DG-iNL4kAR7LtM_6r5-ULb8265lyS0w=.1780acae-a22a-4bc8-aef5-e287de05f718@github.com>
Message-ID: <EZ9rVA19-H3fFopQktMO_vRewVyQ8e-rDGMd66vzckY=.fc400c76-a924-4428-9d6d-54df6de77b6b@github.com>

On Tue, 23 Sep 2025 18:59:10 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> All parameters of offset should be changed to encoded_value.
>> 
>> I guess you mean change from `value` to encoded_value in `CompactHashtable`?
>> I did not touch the parameter name `offset` in read_value_from_compact_hashtable (which is used in OffsetCompactHashtable), as I think it means `offset` intentionally.
>> But please correct me if I'm understanding wrongly.
>
> Modify from `offset`/`value` to `encoded_value` in CompactHashtable template parameters.

Yes, that's what I wanted, rename the field/params in CompactHashtable to `encoded_value`. We can leave `offset` in the other places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2373504011

From iklam at openjdk.org  Tue Sep 23 21:39:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 21:39:49 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v4]
In-Reply-To: <7Uuat45VgibB-QxDNYfLawOn5wQY0JWiMgJJ_b3nfQk=.a30550db-d9db-4be8-9cc6-28e1b6ea0e07@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <7Uuat45VgibB-QxDNYfLawOn5wQY0JWiMgJJ_b3nfQk=.a30550db-d9db-4be8-9cc6-28e1b6ea0e07@github.com>
Message-ID: <U3SvIrgTTv8l4wzdkZ8T2Bau3G_q5HVg0EZSK_mm4XM=.9b784b3e-71ea-45f5-8654-89b07ec90a42@github.com>

On Tue, 23 Sep 2025 19:01:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

src/hotspot/share/classfile/compactHashtable.hpp line 98:

> 96: 
> 97:     u4 value() {
> 98:       return _encoded_value;

The accessor should also be renamed to `encoded_value()`. There are also comments like `(hash, value)` that should also be renamed,

src/hotspot/share/classfile/compactHashtable.hpp line 197:

> 195: //   - The 0-th bucket is a REGULAR_BUCKET_TYPE with two entries
> 196: //   - The 1-st bucket is a VALUE_ONLY_BUCKET_TYPE with one entry.
> 197: //   - The 2-th bucket is a REGULAR_BUCKET_TYPE with zeo entries.

Sorry I had some typos in my original suggestion. Here's the fixed version. I think this will be easier to read:

Suggestion:

//   - Bucket #0 is a REGULAR_BUCKET_TYPE with two entries
//   - Bucket #1 is a VALUE_ONLY_BUCKET_TYPE with one entry.
//   - Bucket #2 is a REGULAR_BUCKET_TYPE with zero entries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2373513100
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2373512782

From iklam at openjdk.org  Tue Sep 23 21:53:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 21:53:47 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <clDorkwjc-jWt_GNucsHej1SdDrFA6BT66Q8px3F_V4=.9cd14708-9a8e-4908-b1c7-c06990b7ae0a@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <clDorkwjc-jWt_GNucsHej1SdDrFA6BT66Q8px3F_V4=.9cd14708-9a8e-4908-b1c7-c06990b7ae0a@github.com>
Message-ID: <llVCzQM3A79Wzj18pU3gHXakKg5CuYmqL7mwx0SZqKU=.ef5920ac-6a5f-423c-be7d-8b7afafb95fd@github.com>

On Tue, 23 Sep 2025 06:38:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Forgot to check in code that was supposed in the last changeset
>>  - @dholmes-ora review comments; also cleaned up code and fixed incorrect comment
>
> src/hotspot/share/cds/lambdaFormInvokers.cpp line 203:
> 
>> 201:       char *buf = NEW_RESOURCE_ARRAY(char, len);
>> 202:       memcpy(buf, (char*)h_bytes->byte_at_addr(0), len);
>> 203:       ClassFileStream st((u1*)buf, len, "jrt:/java.base");
> 
> Are lambdaForms only ever from java.base?

This code regenerates the following 4 classes, which are in java.base:

- java.lang.invoke.Invokers$Holder
- java.lang.invoke.DirectMethodHandle$Holder
- java.lang.invoke.DelegatingMethodHandle$Holder
- java.lang.invoke.LambdaForm$Holder

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2373527587

From iklam at openjdk.org  Tue Sep 23 21:53:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 21:53:48 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <hOz9g-oc9IL0DAV7tcnK0J1Z7TUfBLEjGTOOItBEUT4=.52b10234-a365-4534-bf1e-e6d5e855af4d@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <eRSgNCnt2_GrAGGhFNcx0aQsbygiI1fI-UZ3KNQXxMY=.fdba5c6e-c231-4b7a-8f06-197c1610b1c8@github.com>
 <V2HGym3lEWcQllWrxNhUSSxTfjqwUcngBwo48SpkODk=.2edf6741-4f78-4cb1-a6ba-f6af7577a4f0@github.com>
 <hOz9g-oc9IL0DAV7tcnK0J1Z7TUfBLEjGTOOItBEUT4=.52b10234-a365-4534-bf1e-e6d5e855af4d@github.com>
Message-ID: <OH0hH3pK0u2Rivr_2r06DS6z2QBh4uIhPfkssQv3wzw=.3fcc20d3-1f43-4640-8e9e-30aba402ed8e@github.com>

On Tue, 23 Sep 2025 06:32:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I copied the code from here. Is this style OK for jtreg tests?
>> 
>> https://github.com/openjdk/jdk/blob/61c5245bf7d6626b0c816612adcb0d94d6863644/test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp#L44-L52
>
> I don't know if that one passes `-Xcheck:jni` either (I think we only run runtime tests with `-Xcheck:jni`), so please check else it may fail in tier4. Thanks

I ran the new test with `-Xcheck:jni` and it passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27412#discussion_r2373527367

From iklam at openjdk.org  Tue Sep 23 21:53:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 23 Sep 2025 21:53:46 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
Message-ID: <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>

> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
> 
> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
> 
> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
> 
> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - Forgot to check in code that was supposed in the last changeset
 - @dholmes-ora review comments; also cleaned up code and fixed incorrect comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27412/files
  - new: https://git.openjdk.org/jdk/pull/27412/files/c4af945c..01c07e69

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

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

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

From dholmes at openjdk.org  Tue Sep 23 21:56:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Sep 2025 21:56:07 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v3]
In-Reply-To: <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
 <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
Message-ID: <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>

On Tue, 23 Sep 2025 16:57:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 49:
>> 
>>> 47:     // the latter can be changed by the user.
>>> 48:     // Any changes to this needs to be synchronized with HotSpot.
>>> 49:     private static final String tmpdir;
>> 
>> So we can't cache this any more?
>
> Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?

I would save it in a local in the constructor and pass it to `createAttachFile` rather than passing the pid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2373540696

From dholmes at openjdk.org  Wed Sep 24 01:56:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Sep 2025 01:56:29 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>
Message-ID: <DdFim4h1Gptq3IH-oakqmcOMeHd5I8XzrJfRIxft7Bw=.f8c098b3-f488-4237-af44-87b21dd1e7a5@github.com>

On Tue, 23 Sep 2025 21:53:46 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
>> 
>> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
>> 
>> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
>> 
>> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to check in code that was supposed in the last changeset
>  - @dholmes-ora review comments; also cleaned up code and fixed incorrect comment

Okay - looks good.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27412#pullrequestreview-3260337425

From dzhang at openjdk.org  Wed Sep 24 02:07:04 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 24 Sep 2025 02:07:04 GMT
Subject: Withdrawn: 8368180: RISC-V: Remove redundant
 ext_Zicboz.enable_feature()
In-Reply-To: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
References: <qZkwaJTYCU8fPQVVi1NXmtBSH_1kfs07k6rnrlYupG8=.9f71ea29-525b-4b05-9354-689836bd4e02@github.com>
Message-ID: <WiQttBEYdR94JT9YjNX5j1Ebci5CP5d-aI0EuTlFYas=.d34d050f-bced-48d7-8ff9-811b08321296@github.com>

On Sun, 21 Sep 2025 10:52:28 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi,
> Can you help to review this patch? Thanks!
> 
> We can clean up the duplicate call to ext_Zicboz.enable_feature() in VM_Version::rivos_features(), as it is already invoked at https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L286

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Wed Sep 24 06:33:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:33:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:

> 206:                 Object parkBlocker = snapshot.parkBlocker();
> 207:                 if (parkBlocker != null) {
> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)

This was `if (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allow L209 to use owner.threadId(). It also is consistent with the other use of pattern matching with instanceof in this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374569271

From dholmes at openjdk.org  Wed Sep 24 06:41:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 24 Sep 2025 06:41:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:

> 50: 
> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
> 52:     private Thread parkBlockerOwner;

Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374595923

From alanb at openjdk.org  Wed Sep 24 06:41:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 06:41:17 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <YhKAzx3Cb7oPMgpybD50CIu2zxCBEm71Fsg4Oo5ID0g=.fffb9b8e-a4bf-4a6a-9e78-c3ce82858ec3@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:

> 693:     }
> 694: 
> 695:     /**

In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374587163

From alanb at openjdk.org  Wed Sep 24 07:07:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Sep 2025 07:07:17 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
Message-ID: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>

On Wed, 24 Sep 2025 06:38:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
> 
>> 50: 
>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>> 52:     private Thread parkBlockerOwner;
> 
> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?

The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2374672607

From mli at openjdk.org  Wed Sep 24 08:34:33 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 24 Sep 2025 08:34:33 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v5]
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> Thanks

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  rename 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27360/files
  - new: https://git.openjdk.org/jdk/pull/27360/files/e90142f6..f3009cdc

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

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

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

From mli at openjdk.org  Wed Sep 24 08:34:37 2025
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 24 Sep 2025 08:34:37 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v4]
In-Reply-To: <U3SvIrgTTv8l4wzdkZ8T2Bau3G_q5HVg0EZSK_mm4XM=.9b784b3e-71ea-45f5-8654-89b07ec90a42@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <7Uuat45VgibB-QxDNYfLawOn5wQY0JWiMgJJ_b3nfQk=.a30550db-d9db-4be8-9cc6-28e1b6ea0e07@github.com>
 <U3SvIrgTTv8l4wzdkZ8T2Bau3G_q5HVg0EZSK_mm4XM=.9b784b3e-71ea-45f5-8654-89b07ec90a42@github.com>
Message-ID: <gG_vigqc138vqGROIUtFwu36dOm4geQeefuGMOf4Lek=.8b53d080-8844-41ee-b0a1-04b1dfe57102@github.com>

On Tue, 23 Sep 2025 21:37:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename
>
> src/hotspot/share/classfile/compactHashtable.hpp line 98:
> 
>> 96: 
>> 97:     u4 value() {
>> 98:       return _encoded_value;
> 
> The accessor should also be renamed to `encoded_value()`. There are also comments like `(hash, value)` that should also be renamed,

make sense, updated.

> src/hotspot/share/classfile/compactHashtable.hpp line 197:
> 
>> 195: //   - The 0-th bucket is a REGULAR_BUCKET_TYPE with two entries
>> 196: //   - The 1-st bucket is a VALUE_ONLY_BUCKET_TYPE with one entry.
>> 197: //   - The 2-th bucket is a REGULAR_BUCKET_TYPE with zeo entries.
> 
> Sorry I had some typos in my original suggestion. Here's the fixed version. I think this will be easier to read:
> 
> Suggestion:
> 
> //   - Bucket #0 is a REGULAR_BUCKET_TYPE with two entries
> //   - Bucket #1 is a VALUE_ONLY_BUCKET_TYPE with one entry.
> //   - Bucket #2 is a REGULAR_BUCKET_TYPE with zero entries.

Thanks, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2374960090
PR Review Comment: https://git.openjdk.org/jdk/pull/27360#discussion_r2374959506

From duke at openjdk.org  Wed Sep 24 09:12:16 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Wed, 24 Sep 2025 09:12:16 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
Message-ID: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>

On Tue, 23 Sep 2025 15:33:22 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> anyone who is parsing the output of jcmd's programmatically ... since this change can potentially break that code

@tstuefe Do you think we would need a CSR for this kind of change?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327343529

From stuefe at openjdk.org  Wed Sep 24 09:37:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 09:37:01 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <i7n8tXj8Wzy5M0y8Bdn5h75eFDFNlTZMgkJBbKSBd8o=.2f43a860-6d33-4cb9-bed4-d1176ac82bf4@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

@larry-cable 
> anyone who is parsing the output of jcmd's programmatically ... since
this change can potentially break that code

yeah, true

@Domest0s 
Hmm, rather than breaking compatibility and requiring a CSR, I now also opt for an option. We are usually not so strict with changing individual commands, but I agree with Larry that changing the format of all commands may be a problem. 

Thinking this a bit further. We may have the same discussion in the future whenever we do fundamental changes to jcmd output. 

As an arbitrary example, let's say someone wants to report the jcmd runtime back at the end of every command (I recently needed that, but abandoned the PR). E.g. a trailing "321ms". Or some other statistics or process specs. Do we want a new diagnostic switch every time? That could get confusing quickly, and these switches need testing.

How about a single "enable jcmd legacy output format" setting. By default on. Behind this setting we guard all future changes that severely change the output of commands. Anyone wanting a stable output would define that setting. 

And how about making this switch a standard *jcmd* option, not a JVM setting? Typically, this decision is made by the analyst running jcmd. That is the person wanting to post-process the output. A JVM switch means the analyst has to restart the JVM with new command-line parameters. That is uncomfortable, and the analyst may even be able to do that (often can't restart client production servers; maybe not even change VM parameters).

Opinions?

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327445191

From mhaessig at openjdk.org  Wed Sep 24 12:00:20 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 24 Sep 2025 12:00:20 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: <OqHedOUnvbvpWP-wxFSQ-tT8vzpkKfndlbBzmpun-Fk=.94ced09e-0ed3-42ca-ace4-14473a97bede@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 again for this extensive cleanup. I did another, more thorough, pass and have a few questions and suggestions.

src/hotspot/cpu/arm/arm_32.ad line 436:

> 434:   bool far = (_method == nullptr) ? maybe_far_call(this) : !cache_reachable();
> 435:   return (far ? 3 : 1) * NativeInstruction::instruction_size;
> 436: }

Why do we still need the `instruction_size` offset? Are all static java calls now method handles?

src/hotspot/cpu/arm/frame_arm.cpp line 365:

> 363:       DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp));
> 364:     }
> 365:   }

All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects.

src/hotspot/cpu/arm/frame_arm.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/cpu/arm/register_arm.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/debugInfoRec.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/nmethod.inline.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/code/pcDesc.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/jvmci/jvmciCodeInstaller.hpp line 1:

> 1: /*

Please update the copyright year.

src/hotspot/share/opto/matcher.hpp line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java line 1:

> 1: /*

Please update the copyright year.

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

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java line 1:

> 1: /*

Please update the copyright year.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java line 1:

> 1: /*

Please update the copyright year.

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

Changes requested by mhaessig (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3262358336
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375411757
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375419504
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375518959
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519168
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519398
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375523797
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524042
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524330
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524675
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525018
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525797
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375526227
PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375527000

From cnorrbin at openjdk.org  Wed Sep 24 14:04:37 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 24 Sep 2025 14:04:37 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity
Message-ID: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>

Hi everyone,

The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers.

For example, consider the call sequence for `os::available_memory()`:

os::available_memory()
        |
        v
os::Linux::available_memory()
        |--------------------------------------------
        v                                           v    
OSContainer::memory_limit_in_bytes()       or return host physical memory
        |
        v
CgroupSubsystem::memory_limit_in_bytes()
        |--------------------------------------------
        v                                           v
return os::Linux::physical_memory()        or return cgroup v1/v2 limit


This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality:
* `os::Linux` should focus solely on actual machine memory values.
* `CgroupSubsystem` should focus exclusively on cgroup memory limits.
* The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized.


A revised structure separates these responsibilities:

os::available_memory()
        |--------------------------------------------
        v                                           v
OSContainer::memory_limit_in_bytes()       or os::Linux::available_memory()                       
        |--------------------------------------------
        v                                           v
CgroupSubsystem::memory_limit_in_bytes()   os::Linux::physical_memory()
        |
        v
return bounded cgroup v1/v2 limit


With these changes:
* `os::Linux` only retrieves machine values.
* `CgroupSubsystem` works exclusively with cgroup limits.
* `OSContainer` fetches and passes bounds for the cgroup values.
* The decision of container or machine value is done in the `os` layer.

The concrete code changes include:
* Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`).
* Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also refactored to use the new bool and reference interface introduced in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086).
* Moving accessing host values from `CgroupSubsystem` to `OSContainer`, and abstracting `CgroupSubsystem` to use more generic limits (e.g. `upper_mem_bound`) instead of a direct system reference (e.g. `host_mem`). 


Note: I intentionally kept the `julong` parameter types unchanged. I believe it's better to update all types simultaneously in [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606) instead to ensure the change is complete and consistent.

Testing:
* Oracle tiers 1-3.
* Container tests on cgroup v1 and v2 systems.

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

Commit messages:
 - keep cgroupsubsystem separate
 - keep os::linux separate

Changes: https://git.openjdk.org/jdk/pull/27470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292984
  Stats: 135 lines in 9 files changed: 32 ins; 27 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/27470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27470/head:pull/27470

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

From stuefe at openjdk.org  Wed Sep 24 16:01:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 16:01:54 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <074c99da-4cc8-4a5c-813d-c80eff1bdf90@oracle.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <074c99da-4cc8-4a5c-813d-c80eff1bdf90@oracle.com>
Message-ID: <m_KKFdN6syUqPtWPq1x-gzlWDE-GK2kFsKQS1joRYKA=.aa25d740-fb6d-4119-ba2e-983c1f78b71d@github.com>

On Wed, 24 Sep 2025 15:19:18 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> makes sense, I have a (much) larger dream for jcmd etc that I want to work on:
> 
> 1) add Unix Domain Socket support to the (sun) enbedded httpserver 2) expose a UDS endpoint for Jcmds' 3)? add http+json as a transport for commands and responses 4) add mechanism for DCmd to render in json
> 
> with json as a payload format such additions would be much simpler...(in theory at least)

That sounds interesting, and useful.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3329646138

From stuefe at openjdk.org  Wed Sep 24 16:01:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Sep 2025 16:01:54 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
Message-ID: <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>

On Wed, 24 Sep 2025 09:09:22 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> see inline\.\.\.
>> 
>> On 9\/24\/25 2\:37 AM\, Thomas Stuefe wrote\:
>>> On Thu\, 18 Sep 2025 14\:57\:44 GMT\, Ivan Bereziuk \<duke at openjdk\.org> wrote\:
>>>
>>>> \`jcmd\` provides great diagnostics but many commands lack a timestamp in their output\.
>>>> Adding a timestamp to the output of some would add value for those debugging JVM data\.
>>>>
>>>> Some diagnostic commands already provide timestamps\. For example \`Thread\.print\` already prints one of \"yyyy\-MM\-dd HH\:mm\:ss\" format\.
>>>>
>>>> Adding timestamps to all diagnostic \`jcmd\` commands with a non\-throw\-away STDOUT\.
>>>>
>>>> The exceptions are\:
>>>> \* \`VM\.uptime\` \- command run with \`\-date\` argument will also print a timestamp\;
>>>> \* \`VM\.system\_properties\` \- already lists timestamp
>>>> \* \`Thread\.dump\_to\_file\` \- the content dumped to file already has a timestamp\;
>>>> \* \`VM\.version\`
>>> \@<!-- -->larry\-cable
>>>> anyone who is parsing the output of jcmd\'s programmatically \.\.\. since
>>> this change can potentially break that code
>>>
>>> yeah\, true
>> 
>> thanks\!
>>> \@<!-- -->Domest0s
>>> Hmm\, rather than breaking compatibility and requiring a CSR\, I now also opt for an option\. We are usually not so strict with changing individual commands\, but I agree with Larry that changing the format of all commands may be a problem\.
>> 
>> cheers\!
>>>
>>> Thinking this a bit further\. We may have the same discussion in the future whenever we do fundamental changes to jcmd output\.
>> 
>> agreed\!
>>>
>>> As an arbitrary example\, let\'s say someone wants to report the jcmd runtime back at the end of every command \(I recently needed that\, but abandoned the PR\)\. E\.g\. a trailing \"321ms\"\. Or some other statistics or process specs\. Do we want a new diagnostic switch every time\? That could get confusing quickly\, and these switches need testing\.
>> 
>> agreed
>>>
>>> How about a single \"enable jcmd legacy output format\" setting\. By default on\. Behind this setting we guard all future changes that severely change the output of commands\. Anyone wanting a stable output would define that setting\.
>> 
>> agreed
>>>
>>> And how about making this switch a standard \*jcmd\* option\, not a JVM setting\? Typically\, this decision is made by the analyst running jcmd\. That is the person wanting to post\-process the output\. A JVM switch means the analyst has to restart the JVM with new command\-line parameters\. That is uncomfortable\, and the analyst may even be able to do that \(often ca...
>
>> anyone who is parsing the output of jcmd's programmatically ... since this change can potentially break that code
> 
> @tstuefe Do you think we would need a CSR for this kind of change?

@Domest0s Let's see if everyone agrees on this.

My proposal would entail
- adding a new standard option to jcmd
- somehow funneling that option to the JVM
- the option should be optional, so that:
  - old jcmd still works with new JVMs (and produces legacy jcmd output)
  - new jcmd still works with old JVMs (and produces legacy jcmd output)

How complex would this be? There are two approaches to this. You can either create a new attach listener protocol (we already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or, you can expand the jcmd parsing (see `jcmd(AttachOperation* op, attachStream* out)` in attachListener.cpp).

Not sure whether this would be complex. I understand if this is expanding the scope of your PR too much, in which case I think you should add a new JVM command line option that preserves legacy jcmd output format.

I think you need a CSR in both cases. Not exactly because compatibility would be broken (the jcmd output should stay the same unless this option is explicitly enabled), but because it makes sense to think a bit about the format of this new jcmd option or this new command line flag, and to make the new command line flag product.

Just my 5 cents, let's see what others think first

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3329641686

From matsaave at openjdk.org  Wed Sep 24 17:35:36 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 24 Sep 2025 17:35:36 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>
Message-ID: <CwyQDWY5OpIar5perVp7gqvGWxV5XB4A5g1dqPjkIuI=.45f28f4b-e449-4b40-9340-460de58a36bd@github.com>

On Tue, 23 Sep 2025 21:53:46 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
>> 
>> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
>> 
>> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
>> 
>> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to check in code that was supposed in the last changeset
>  - @dholmes-ora review comments; also cleaned up code and fixed incorrect comment

Fix looks simple and tests look good. Thanks!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27412#pullrequestreview-3263951645

From amenkov at openjdk.org  Wed Sep 24 19:52:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 19:52:22 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
 <Hyft89RsM69BGk6qn5yce1-onp39CC0jfXm3a9slbHQ=.8750c3b8-1337-42e2-aadc-c4fd86860406@github.com>
Message-ID: <dtVog4jA3KB_1c4aGc9RjCeNz9J8JTeyQZWvcrg1mfw=.927816fe-0d84-4b11-a594-4fa701a7eda6@github.com>

On Wed, 24 Sep 2025 15:58:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> My proposal would entail
>     * adding a new standard option to jcmd
>     * somehow funneling that option to the JVM
>     * the option should be optional, so that:
>       * old jcmd still works with new JVMs (and produces legacy jcmd output)
>       * new jcmd still works with old JVMs (and produces legacy jcmd output)
> How complex would this be? There are two approaches to this. You can either create a new attach listener protocol (we already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or, you can expand the jcmd parsing (see `jcmd(AttachOperation* op, attachStream* out)` in attachListener.cpp).

ATTACH_API_V2 supports "options".
Client (jcmd) detects options supported by the target VM ("getversion options" command) and can set option values in attach command request.
Currently the only supported option is "streaming" (it allows turn off streaming output).
The option is needed only for tests and needs to work for all attach tools (jcmd, jstack, etc.), so it can be set by specifying java property launching attach tool (like `jcmd -J-Djdk.attach.allowStreamingOutput=false PID command`)

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3330432466

From amenkov at openjdk.org  Wed Sep 24 19:59:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 19:59:55 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/b0425b68..5a2a8dc7

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

  Stats: 19 lines in 3 files changed: 5 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27457/head:pull/27457

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

From amenkov at openjdk.org  Wed Sep 24 20:04:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:32 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <nT132_xU8Usd00or8Q3B9G4hJkepXd5C4ZA-jm711rM=.3b098dad-229c-4abb-aac0-e868fc83c2f3@github.com>
Message-ID: <avSCzUEBJ8P33fqLCvkZ2xhW_Nh3f7DmOjA4eeBvK3s=.de4371a3-0bcc-473b-8a47-7e22e7137967@github.com>

On Wed, 24 Sep 2025 06:30:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 208:
> 
>> 206:                 Object parkBlocker = snapshot.parkBlocker();
>> 207:                 if (parkBlocker != null) {
>> 208:                     String suffix = (snapshot.parkBlockerOwner() != null)
> 
> This was `String suffix = (snapshot.parkBlockerOwner() instanceof Thread owner)` in the original prototype. It avoids the null check and allows L209 to use owner.threadId(). I think I'd prefer it here as it makes it consistent with the other uses of pattern matching with instanceof in this code.

Fixed (and for json version too)

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 695:
> 
>> 693:     }
>> 694: 
>> 695:     /**
> 
> In the contains methods, the comment has "contain the given text", it should "containing the given text". (this was spotted when adding the find method).

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925109
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376926531

From amenkov at openjdk.org  Wed Sep 24 20:04:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 20:04:34 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <W4gijDLZQT6fCKm03E5xaNIIE_MFdvaMr-9eEPIHfJ4=.017891f1-5b18-4895-ab70-a0b54f31b31b@github.com>
 <Cpl13QaRHfsYB3Wv2DxTuuf3FZQcGnlkhwuO6MoH0yY=.b5af99ad-b837-4bdd-8720-f777c2382b86@github.com>
Message-ID: <D8IghIMuy52RLYS8IWTSljAXxKR5rqvIYtM8RBuMv1c=.3bd5aef4-4528-4946-b080-fdf8fc245913@github.com>

On Wed, 24 Sep 2025 07:04:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 52:
>> 
>>> 50: 
>>> 51:     // the owner of the blockerObject when the object is park blocker and is AQS
>>> 52:     private Thread parkBlockerOwner;
>> 
>> Just wondering whether it makes sense to make the owner field part of the `ThreadBlocker` record?
>
> The parkBlocker is a property of the thread. When the parkBlocker is an AbstractOwnableSynchronizer then the owner is a property of that park blocker type. So yes, in modelling terms it would be more accurate. In practical terms it doesn't matter as it's all encapsulated but there is likely more work in this area so it would be better to get it right.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2376925797

From iklam at openjdk.org  Wed Sep 24 20:55:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 24 Sep 2025 20:55:29 GMT
Subject: RFR: 8368182: AOT cache creation fails with class defined by JNI
 [v2]
In-Reply-To: <DdFim4h1Gptq3IH-oakqmcOMeHd5I8XzrJfRIxft7Bw=.f8c098b3-f488-4237-af44-87b21dd1e7a5@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
 <ipHvhH9gfGE_kZH8LamIFpYtNHWRiFZ6RG4arsK1Gls=.bc01b3e7-9cd6-4397-9764-c7609f528fc1@github.com>
 <DdFim4h1Gptq3IH-oakqmcOMeHd5I8XzrJfRIxft7Bw=.f8c098b3-f488-4237-af44-87b21dd1e7a5@github.com>
Message-ID: <aldoN36jgcP7WcSrDFbSxYS3s3vodbroiqUULym75OU=.86e834ac-b7d0-41e4-8b44-8f00ca03b710@github.com>

On Wed, 24 Sep 2025 01:53:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Forgot to check in code that was supposed in the last changeset
>>  - @dholmes-ora review comments; also cleaned up code and fixed incorrect comment
>
> Okay - looks good.

Thanks @dholmes-ora @matias9927 for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27412#issuecomment-3330668417

From iklam at openjdk.org  Wed Sep 24 20:55:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 24 Sep 2025 20:55:32 GMT
Subject: Integrated: 8368182: AOT cache creation fails with class defined by
 JNI
In-Reply-To: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
References: <j1jjmERBPpZgAvJTELg78jUqcU8rIv2shZYhl1szGf4=.ef018f0b-fbdd-41c8-81c5-3ec124cb9515@github.com>
Message-ID: <TUGvdZsVSeN6vbh2e4LzqRcI-P5dtpZEXPZM7ptmRfg=.4680928b-8050-4794-817e-c33d106e15fa@github.com>

On Sun, 21 Sep 2025 20:00:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The AOT cache should store only classes from known locations (modules file, classpath, module path). Classes defined by JNI should be excluded.
> 
> However, the `ik->set_shared_classpath_index(0)` call in classLoader.cpp had the incorrect side effect of allowing all classes defined by JNI to be stored in the AOT configuration file at the end of the training run. This causes failure when we use the AOT configuration file to create the AOT cache.
> 
> The fix is to set the `shared_classpath_index` of such classes to -1 so they are excluded.
> 
> Also, `LambdaFormInvokers::regenerate_holder_classes()` needs to be updated to specify a non-null code source, so that the regenerated holder classes are not excluded.

This pull request has now been integrated.

Changeset: 8f87fdce
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f87fdce0b17f3edd453054461895330b82e8a71
Stats:     179 lines in 4 files changed: 174 ins; 3 del; 2 mod

8368182: AOT cache creation fails with class defined by JNI

Reviewed-by: dholmes, matsaave

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

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

From iklam at openjdk.org  Wed Sep 24 22:22:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 24 Sep 2025 22:22:48 GMT
Subject: RFR: 8367981: Update CompactHashtable comments [v5]
In-Reply-To: <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
Message-ID: <_ENHK97QTPpGR4z6SezGzyp6vXSJRdSjiQD6nftpmxo=.2a5db5d9-4cc5-4e35-9593-fd5455a10f2f@github.com>

On Wed, 24 Sep 2025 08:34:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename 2

LGTM!

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27360#pullrequestreview-3264910554

From duke at openjdk.org  Wed Sep 24 22:27:28 2025
From: duke at openjdk.org (Larry Cable)
Date: Wed, 24 Sep 2025 22:27:28 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
Message-ID: <FR9QEZTX6k0npRCC3rYjUjRGOlxFez7pME9IRxzmp7Y=.dbc79198-11f4-45f5-ab78-3f34c0564d04@github.com>

On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> `jcmd` provides great diagnostics but many commands lack a timestamp in their output.
> Adding a timestamp to the output of some would add value for those debugging JVM data.
> 
> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format.
> 
> Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away STDOUT.
> 
> The exceptions are:
> * `VM.uptime` - command run with `-date` argument will also print a timestamp;
> * `VM.system_properties` - already lists timestamp
> * `Thread.dump_to_file` - the content dumped to file already has a timestamp;
> * `VM.version`

On 9/24/25 12:50 PM, Alex Menkov wrote:
> *alexmenkov* left a comment (openjdk/jdk#27368) 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$>
>
>     My proposal would entail
>     * adding a new standard option to jcmd
>     * somehow funneling that option to the JVM
>     * the option should be optional, so that:
>     * old jcmd still works with new JVMs (and produces legacy jcmd output)
>     * new jcmd still works with old JVMs (and produces legacy jcmd output)
>     How complex would this be? There are two approaches to this. You
>     can either create a new attach listener protocol (we already have
>     ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or,
>     you can expand the jcmd parsing (see |jcmd(AttachOperation* op,
>     attachStream* out)| in attachListener.cpp).
>
> ATTACH_API_V2 supports "options".
> Client (jcmd) detects options supported by the target VM ("getversion 
> options" command) and can set option values in attach command request.
> Currently the only supported option is "streaming" (it allows turn off 
> streaming output).
> The option is needed only for tests and needs to work for all attach 
> tools (jcmd, jstack, etc.), so it can be set by specifying java 
> property launching attach tool (like |jcmd 
> -J-Djdk.attach.allowStreamingOutput=false PID command|)
>

sounds like a plan!

> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGRSQRLDJZAM3LPRT3ULYW5AVCNFSM6AAAAACG4ANNIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZQGQZTENBWGY__;!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYk7VM8-7g$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------oR0JTaz5Fop00jaWhAnzYKGf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 9/24/25 12:50 PM, Alex Menkov wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/69548902?s=20&amp;v=4" moz-do-not-send="true"><strong>alexmenkov</strong> left a comment <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$" moz-do-not-send="true">(openjdk/jdk#27368)</a></div>
      <blockquote>
        <p dir="auto">My proposal would entail<br>
          * adding a new standard option to jcmd<br>
          * somehow funneling that option to the JVM<br>
          * the option should be optional, so that:<br>
          * old jcmd still works with new JVMs (and produces legacy jcmd
          output)<br>
          * new jcmd still works with old JVMs (and produces legacy jcmd
          output)<br>
          How complex would this be? There are two approaches to this.
          You can either create a new attach listener protocol (we
          already have ATTACH_API_V2 vs ATTACH_API_V1, so the precedence
          is there). Or, you can expand the jcmd parsing (see <code class="notranslate">jcmd(AttachOperation* op, attachStream*
            out)</code> in attachListener.cpp).</p>
      </blockquote>
      <p dir="auto">ATTACH_API_V2 supports &quot;options&quot;.<br>
        Client (jcmd) detects options supported by the target VM
        (&quot;getversion options&quot; command) and can set option values in
        attach command request.<br>
        Currently the only supported option is &quot;streaming&quot; (it allows
        turn off streaming output).<br>
        The option is needed only for tests and needs to work for all
        attach tools (jcmd, jstack, etc.), so it can be set by
        specifying java property launching attach tool (like <code class="notranslate">jcmd
          -J-Djdk.attach.allowStreamingOutput=false PID command</code>)</p>
    </blockquote>
    <br>
    sounds like a plan!<br>
    <br>
    <blockquote type="cite" ***@***.***">
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27368*issuecomment-3330432466__;Iw!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYmYB9_KGw$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SGRSQRLDJZAM3LPRT3ULYW5AVCNFSM6AAAAACG4ANNIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZQGQZTENBWGY__;!!ACWV5N9M2RV99hQ!L8Ino0e59huBM_uRbUgs_2H_F9z8ErphlRCLbOg46qe85WuOwQe9PPmlOD1eOCuSVjCV2Xyj6sI_YJnNWYk7VM8-7g$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67WKNASEIPXUMLRQ5RD3ULYW5A5CNFSM6AAAAACG4ANNIKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWGQJO5E.gif" height="1" width="1" alt="" moz-do-not-send="true"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/27368/c3330432466</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/27368#issuecomment-3330432466",
"url": "https://github.com/openjdk/jdk/pull/27368#issuecomment-3330432466",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------oR0JTaz5Fop00jaWhAnzYKGf--

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3330902786

From sspitsyn at openjdk.org  Thu Sep 25 01:42:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Sep 2025 01:42:48 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377441081

From dholmes at openjdk.org  Thu Sep 25 02:06:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:29 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Looks good.

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:

> 81:                           "owner": {
> 82:                             "type": "string",
> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."

Is it possible for there to not be an owner? If so what does this report?

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 696:

> 694: 
> 695:     /**
> 696:      * Finds the line of plain text thread dump containing the given text.

Suggestion:

     * Finds the line of a plain text thread dump containing the given text.

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

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3265266068
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377469785
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472831

From dholmes at openjdk.org  Thu Sep 25 02:06:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 02:06:31 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
Message-ID: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>

On Thu, 25 Sep 2025 01:40:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?

The original "contain" was correct. Alternatively:
> Returns true if lines is a plain text thread dump containing the given text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377472427

From alanb at openjdk.org  Thu Sep 25 06:32:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:32:31 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
Message-ID: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>

On Thu, 25 Sep 2025 01:59:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
> 
>> 81:                           "owner": {
>> 82:                             "type": "string",
>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
> 
> Is it possible for there to not be an owner? If so what does this report?

In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377894888

From alanb at openjdk.org  Thu Sep 25 06:36:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:36:48 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <cIjt_YSfVx-OGTkQwCrj1Hn9HzGcfRknNXxUP4lyWpA=.61e50aa3-7481-4c30-be69-0bf70df76a46@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:

> 85:                           "required": [
> 86:                             "object"
> 87:                           ]

At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377903090

From alanb at openjdk.org  Thu Sep 25 06:50:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 06:50:01 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <oxZPKpXQMZm38uh-MplGAT_FK-eQhc1Tjf8fV10KDhs=.b20c0974-b2ed-4a5a-8dd4-513db8f4693e@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:

> 443:             assertNotNull(parkBlocker);
> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
> 445: 

Will you add 8365057 to the `@bug` at the top?

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:

> 298: 
> 299:         /**
> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.

Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377924570
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377928658

From alanb at openjdk.org  Thu Sep 25 07:00:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 07:00:31 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <ca09e194-489b-4523-a00c-70c3517b591c@oracle.com>
 <lreKhzueb-pqRUn0bs65GuXDlXXQWf6uLWtI9nDl7Po=.7dcdc70d-b976-497e-8e52-799d866f3a1f@github.com>
Message-ID: <tuTOeqxpBCJd5jDMbYEmMx8dkGs9-qcA73taHWf_0jY=.5ca6438c-c629-482c-90c9-10cce78536ff@github.com>

On Wed, 24 Sep 2025 09:09:22 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> Do you think we would need a CSR for this kind of change?

The output from several commands have changed over many releases/years, the output from Thread.dump in particular. AFAIK, none of these changes has a CSR, there were only CSRs when new commands were added. That said, if there is some evidence that the output is being parsed then there is a compatibility concern so creating a CSR and RN would prudent.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3332451741

From alanb at openjdk.org  Thu Sep 25 07:08:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 07:08:03 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
Message-ID: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>

On Wed, 24 Sep 2025 19:59:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:

> 45:     private int blockerTypeOrdinal;
> 46:     private Object blockerObject;
> 47:     // the owner of the blockerObject when the object is park blocker and is AQS

Typo here, AQS != AbstractOwnableSynchronizer

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2377970208

From schernyshev at openjdk.org  Thu Sep 25 08:38:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 08:38:41 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v4]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <_7eEGrVgRXbUpI9iMW8So9q4VGbRJcUB5pjND-TblX0=.57aae041-83e6-45eb-b7a7-66052d6d1ba3@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  addressed review comment #2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/de855d37..9ca4aaf0

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

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

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

From schernyshev at openjdk.org  Thu Sep 25 08:46:12 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 08:46:12 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v4]
In-Reply-To: <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
 <_mZBaD6fA4dZANRC-3jA-4Vu2e2FN0ViTrat0_H2bes=.43fcacb1-b2e7-49c9-b821-9765c087d8c2@github.com>
 <vZy2FkRX5gOSp0iEgfrm0D_tCNBtCG5onvxh3qWA2NM=.c5d9f48b-5d0b-4a65-a581-b0b5f2118583@github.com>
 <doea2Uy4C1_IOG7Pb3_ph9ZqoJcK6VKipksqGb_BY_M=.ea75aec3-3d0c-45fd-9354-a87a2e1bdc33@github.com>
Message-ID: <77sm3LvHu0reeiXw8rcTbGCitWVHdBIO9fRCMNOJ9Wo=.bf6fa3f9-cb6e-4602-8c4b-33cf098c4e39@github.com>

On Tue, 23 Sep 2025 21:53:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks David for pointing this out. A different instance with a different PID may have a different temp path, so the path should be specific to the instance. Since we don't need the path outside the constructor, I think we don't need to cache it. On the other hand I see that `getTempDirFromPid` is called twice, once for `.java_pid` and another time in `createAttachFile` when `.java_pid` doesn't exist. Would you suggest storing the path in a local variable in the constructor and then concatenating it with attach file name, or would a non-static member variable be more suitable for this?
>
> I would save it in a local in the constructor and pass it to `createAttachFile` rather than passing the pid.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2378277200

From duke at openjdk.org  Thu Sep 25 08:47:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 25 Sep 2025 08:47:44 GMT
Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when
 running on 64-bit OSes [v10]
In-Reply-To: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
References: <AafCf0JmdKDZXCzv9rHL1PqOeQooBPIBhQPuYZdGMP0=.e7ab2624-43bb-4d0d-ada3-429244f1f4fc@github.com>
Message-ID: <9vKDSge1so828VpIlmbHofhqKak_K-6WSZeON0KyByU=.c81f69d3-3238-4f9b-ad1a-7894830cb74d@github.com>

> Hi, please consider the following changes:
> 
> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. 
> 
> The issue is addressed by changing the output type of all related functions to `uint64_t`.
> 
> Tested in tiers 1 - 5.

Anton Artemov 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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8367485-os-physical-memory-broken-32bit-on-64bit
 - 8367485: Alignment of vars in os_windows.cpp
 - 8367485: Indentation in GCInitLogger::print_memory()
 - 8367485: Changed output format in GCInitLogger::print_memory()
 - 8367485: Addressed reviewers' comments.
 - 8367485: Indentation fix.
 - 8367485: Addressed reviewer's comments.
 - 8367485: Addressed reviewer's comments
 - 8367485: Addressed reviewer's comments.
 - 8367485: Refactoring with uint64_t
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5cd3c0c5...b39817de

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27335/files
  - new: https://git.openjdk.org/jdk/pull/27335/files/791faaeb..b39817de

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

  Stats: 141494 lines in 1287 files changed: 121533 ins; 11590 del; 8371 mod
  Patch: https://git.openjdk.org/jdk/pull/27335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335

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

From schernyshev at openjdk.org  Thu Sep 25 09:36:56 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 09:36:56 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v5]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <JDySXe8YKLNFK5ER6nkCSG_pmDmb3wirJ5ZKLQhSrfM=.c93e9741-d7cf-4825-b370-061b26d3873c@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused native method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/9ca4aaf0..4c96cca5

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

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

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

From azeller at openjdk.org  Thu Sep 25 10:05:51 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 25 Sep 2025 10:05:51 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails
 on non CDS platforms/builds after JDK-8362561
Message-ID: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>

The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
The new subtest test misses the @requires that exists in the other subtests.

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

Commit messages:
 - Add @requires

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

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

From mbaesken at openjdk.org  Thu Sep 25 10:54:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Sep 2025 10:54:21 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic
 fails on non CDS platforms/builds after JDK-8362561
In-Reply-To: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
Message-ID: <Lsx6wdeUVNEAGnZiS0JzblfCbA8VIt7j33fvIfpASss=.3747acfd-5a9a-4f4f-b3fb-c120ad3359c5@github.com>

On Thu, 25 Sep 2025 08:09:07 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
> The new subtest test misses the @requires that exists in the other subtests.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27484#pullrequestreview-3267048821

From schernyshev at openjdk.org  Thu Sep 25 11:22:05 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 25 Sep 2025 11:22:05 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev 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 JDK-8319589
 - Removed unused native method
 - addressed review comment #2
 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - addressed review comments
 - 8319589: Attach from root to a user java process not supported in Mac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/4c96cca5..75dd6fb8

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

  Stats: 325003 lines in 5273 files changed: 226501 ins; 64752 del; 33750 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

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

From sgehwolf at openjdk.org  Thu Sep 25 12:05:46 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 25 Sep 2025 12:05:46 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity
In-Reply-To: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
Message-ID: <eWvz0DaPwzc7l2F6Z-9qsiwUdGD8_PRsg_lyrkTY-Ks=.987e788a-310b-4661-a3c3-4e9f53ce129c@github.com>

On Wed, 24 Sep 2025 13:55:35 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers.
> 
> For example, consider the call sequence for `os::available_memory()`:
> 
> os::available_memory()
>         |
>         v
> os::Linux::available_memory()
>         |--------------------------------------------
>         v                                           v    
> OSContainer::memory_limit_in_bytes()       or return host physical memory
>         |
>         v
> CgroupSubsystem::memory_limit_in_bytes()
>         |--------------------------------------------
>         v                                           v
> return os::Linux::physical_memory()        or return cgroup v1/v2 limit
> 
> 
> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality:
> * `os::Linux` should focus solely on actual machine memory values.
> * `CgroupSubsystem` should focus exclusively on cgroup memory limits.
> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized.
> 
> 
> A revised structure separates these responsibilities:
> 
> os::available_memory()
>         |--------------------------------------------
>         v                                           v
> OSContainer::memory_limit_in_bytes()       or os::Linux::available_memory()                       
>         |--------------------------------------------
>         v                                           v
> CgroupSubsystem::memory_limit_in_bytes()   os::Linux::physical_memory()
>         |
>         v
> return bounded cgroup v1/v2 limit
> 
> 
> With these changes:
> * `os::Linux` only retrieves machine values.
> * `CgroupSubsystem` works exclusively with cgroup limits.
> * `OSContainer` fetches and passes bounds for the cgroup values.
> * The decision of container or machine value is done in the `os` layer.
> 
> The concrete code changes include:
> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`).
> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also refactored to use the new bool and reference interface introduced in [JDK-8357086](https://bugs.openjdk...

Looks good to me, but should probably wait until [JDK-8367485](https://github.com/openjdk/jdk/pull/27335) is integrated.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27470#pullrequestreview-3267322731

From fandreuzzi at openjdk.org  Thu Sep 25 13:51:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 25 Sep 2025 13:51:48 GMT
Subject: RFR: 8368357: Some HotSpot source files have initial blank lines
Message-ID: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>

Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

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

Commit messages:
 - more
 - rm

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

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

From shade at openjdk.org  Thu Sep 25 14:11:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Sep 2025 14:11:11 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic
 fails on non CDS platforms/builds after JDK-8362561
In-Reply-To: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
Message-ID: <WA7eKlnxZwZooCrILZUzYW74Dao6OEeOwiaxAiBbcOM=.6bd9eed3-840e-49f6-86be-ae70b3697b2e@github.com>

On Thu, 25 Sep 2025 08:09:07 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
> The new subtest test misses the @requires that exists in the other subtests.

This makes sense. Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27484#pullrequestreview-3267941031

From stefank at openjdk.org  Thu Sep 25 14:14:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Sep 2025 14:14:42 GMT
Subject: RFR: 8368357: Some HotSpot source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <lhKaO0ggZLrY1CxbKk3RKoOKaxmzKpL7kymrgAJf3ug=.6790d10d-cebe-4882-af71-6a95d85a2203@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

HotSpot code looks good. The other files look good as well, but let's wait for the other group's Reviewers to chime in.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27489#pullrequestreview-3267968546

From ayang at openjdk.org  Thu Sep 25 15:48:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 25 Sep 2025 15:48:38 GMT
Subject: RFR: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <zYhUo2qOp6h71Wu5wXtR1PEprOSTxCoZr34fvb9Vv9E=.2de19e8a-4fcd-4976-ab3a-2b25745a1dd1@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

The title can probably be updated, as the patch changes files outside hotspot.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27489#pullrequestreview-3268425252

From serb at openjdk.org  Thu Sep 25 18:41:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Sep 2025 18:41:16 GMT
Subject: RFR: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <tVNSb83fR9ilotPsfPqRwIoRINMWD7T-9eF8KH6OOqs=.1c5e103d-104e-4721-a3ca-abf799935116@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27489#pullrequestreview-3269026321

From amenkov at openjdk.org  Thu Sep 25 19:09:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:09:13 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v3]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <hmSQ8IzFdvbQzL070v_Y7ojzcRrMqzZty-mljypBNUQ=.da582904-f7a3-4e58-923e-aaa8a71b2ace@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/5a2a8dc7..e8715cc2

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

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

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

From amenkov at openjdk.org  Thu Sep 25 19:33:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:33:58 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v4]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <CuCEjfyczTqDMlXZFRrWd2ZUxdToVbPUO4IYJfOmFYc=.a3ec45fb-48f7-400f-9a34-4e61909112d0@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/e8715cc2..fb3d55ad

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

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

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

From amenkov at openjdk.org  Thu Sep 25 19:34:00 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:00 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <_8WoySTz837HpQQtq3CHgtcMul9v-di6Itlg8i9eDLw=.74a28704-93cf-4553-99ef-5abc6f999e74@github.com>
 <-VWVWqC03kK76gkiGdkn65JRZYsNALKotU0ImMU4axI=.25e58e0a-3a8e-4c6a-9280-4ca00b110879@github.com>
Message-ID: <6He4wm7RD2rsTwbL7449BhfGf2NxMrENHUhuZRr-qcQ=.b5eb75e1-7aa6-435c-9879-da935198baca@github.com>

On Thu, 25 Sep 2025 06:29:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 83:
>> 
>>> 81:                           "owner": {
>>> 82:                             "type": "string",
>>> 83:                             "description": "The thread identifier of the owner when the parkBlocker is an AbstractOwnableSynchronizer."
>> 
>> Is it possible for there to not be an owner? If so what does this report?
>
> In the schema, the only require property of a parkBlocker is "object". The "owner" is optional.

Yes, owner may be absent.
As we discussed in the JBS, owner can release the object at any time (and set "parkBlockerOwner" field to null)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380094231

From amenkov at openjdk.org  Thu Sep 25 19:34:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:34:02 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
Message-ID: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>

On Thu, 25 Sep 2025 02:02:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
>> 
>>> 686: 
>>> 687:     /**
>>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
>> 
>> Nit: Should it be: "...if lines of a plain text thread dump **is** containing" ?
>
> The original "contain" was correct. Alternatively:
>> Returns true if lines is a plain text thread dump containing the given text.

Well.. this was Alan's request to update the comment.
To me original comment was clear and correct.
@AlanBateman , what do you prefer to see here:
- Returns true if lines of a plain text thread dump contain the given text. (original)
- Returns true if lines of a plain text thread dump is containing the given text.
- Returns true if lines is a plain text thread dump containing the given text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380081779

From amenkov at openjdk.org  Thu Sep 25 19:40:45 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:45 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <HNCpHfQDIgYoUPZ1MYH5HQh39LJ7t-w-3adgRfBHZzg=.bbb318b1-4c43-460b-a9a5-8a9183105989@github.com>
Message-ID: <Zax25QuffcAFRfr0gJoz8Lzu3SrZ_4YGEFPbuZ2dpK4=.a4676372-e401-4198-a3da-e77bee4f0fa2@github.com>

On Thu, 25 Sep 2025 07:05:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 47:
> 
>> 45:     private int blockerTypeOrdinal;
>> 46:     private Object blockerObject;
>> 47:     // the owner of the blockerObject when the object is park blocker and is AQS
> 
> Typo here, AQS != AbstractOwnableSynchronizer

Replaced with "AbstractOwnableSynchronizer"

> src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json line 87:
> 
>> 85:                           "required": [
>> 86:                             "object"
>> 87:                           ]
> 
> At L122 the null in the items object should be in quotes, as in "null", and the description ending in ".. null if eliminated" needs a period. There were in the first prototype but didn't make it into the PR patch for some reason. (It came up when using the updated JSON schema, wasn't noticed previously).

Fixed

> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 445:
> 
>> 443:             assertNotNull(parkBlocker);
>> 444:             assertTrue(parkBlocker.contains("java.util.concurrent.locks.ReentrantLock"));
>> 445: 
> 
> Will you add 8365057 to the `@bug` at the top?

Done

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 300:
> 
>> 298: 
>> 299:         /**
>> 300:          * Returns the owner of the parkBlocker if the parkBlocker is an AQS.
> 
> Can you change "AQS" to AbstractOwnableSynchronizer here? It could be changed to AOS too but few will know what it means.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380140551
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139086
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139344
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380139864

From amenkov at openjdk.org  Thu Sep 25 19:40:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:40:40 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/fb3d55ad..bc664ef4

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

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

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

From dcubed at openjdk.org  Thu Sep 25 20:26:54 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 25 Sep 2025 20:26:54 GMT
Subject: RFR: 8368714: [BACKOUT] JDK-8368468 Split out everything but configure
 results from spec.gmk
Message-ID: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>

This reverts commit de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53.

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

Commit messages:
 - 8368714: [BACKOUT] JDK-8368468 Split out everything but configure results from spec.gmk

Changes: https://git.openjdk.org/jdk/pull/27500/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368714
  Stats: 938 lines in 12 files changed: 413 ins; 472 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/27500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27500/head:pull/27500

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

From ihse at openjdk.org  Thu Sep 25 20:26:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 25 Sep 2025 20:26:54 GMT
Subject: RFR: 8368714: [BACKOUT] JDK-8368468 Split out everything but
 configure results from spec.gmk
In-Reply-To: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>
References: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>
Message-ID: <3iWoHOyEwYijWrYrQ3kFMjS56eRsZDvFhFFk5DrCJ0E=.10d978cd-5c3e-4288-90bc-73e346f57c20@github.com>

On Thu, 25 Sep 2025 20:15:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27500#pullrequestreview-3269348023

From dcubed at openjdk.org  Thu Sep 25 20:26:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 25 Sep 2025 20:26:55 GMT
Subject: RFR: 8368714: [BACKOUT] JDK-8368468 Split out everything but
 configure results from spec.gmk
In-Reply-To: <3iWoHOyEwYijWrYrQ3kFMjS56eRsZDvFhFFk5DrCJ0E=.10d978cd-5c3e-4288-90bc-73e346f57c20@github.com>
References: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>
 <3iWoHOyEwYijWrYrQ3kFMjS56eRsZDvFhFFk5DrCJ0E=.10d978cd-5c3e-4288-90bc-73e346f57c20@github.com>
Message-ID: <nSXgARI3ZQNo2GJb2sdeiTlA3ITMUgq1WszpJVxoB9w=.3e83a9d8-18a7-453a-bd0f-c51c3b4bf7b5@github.com>

On Thu, 25 Sep 2025 20:21:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This reverts commit de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53.
>
> Marked as reviewed by ihse (Reviewer).

@magicus  - Thanks for the lightning fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27500#issuecomment-3335814584

From dcubed at openjdk.org  Thu Sep 25 20:57:42 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 25 Sep 2025 20:57:42 GMT
Subject: Integrated: 8368714: [BACKOUT] JDK-8368468 Split out everything but
 configure results from spec.gmk
In-Reply-To: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>
References: <qmLPI0edpWKAdUgOk4U1OC5au06EH9cKTnMaGNJ4pPI=.394a8c3e-a217-4d6e-80c3-2291d66f243e@github.com>
Message-ID: <5Gk8Ta8bn_UX-arg3CY5DfCR2_lPKcqfQLmcbPoZVck=.d2350360-573e-4e55-b924-bc1e0a3de57e@github.com>

On Thu, 25 Sep 2025 20:15:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53.

This pull request has now been integrated.

Changeset: 648582ab
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/648582ab781d98556906c274067f26f856fc0449
Stats:     938 lines in 12 files changed: 413 ins; 472 del; 53 mod

8368714: [BACKOUT] JDK-8368468 Split out everything but configure results from spec.gmk

Reviewed-by: ihse

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

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

From iklam at openjdk.org  Fri Sep 26 02:39:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 02:39:46 GMT
Subject: RFR: 8358597: [asan] Buffer overflow in
 ArchiveBuilder::make_shallow_copy with Symbols
Message-ID: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>

The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan.

The fix is to copy the exact number of bytes for Symbols.

Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable.

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

Commit messages:
 - More clean up
 - 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols

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

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

From iklam at openjdk.org  Fri Sep 26 03:00:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 03:00:10 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic
 fails on non CDS platforms/builds after JDK-8362561
In-Reply-To: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
Message-ID: <Zz_x3deUq6A2nUtTv-BJGue6W2BVctGBQgqWcUW4u_8=.b516906a-5fbd-43a0-99dd-4bf3a70165ad@github.com>

On Thu, 25 Sep 2025 08:09:07 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
> The new subtest test misses the @requires that exists in the other subtests.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27484#pullrequestreview-3269974775

From syan at openjdk.org  Fri Sep 26 03:15:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 26 Sep 2025 03:15:07 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v3]
In-Reply-To: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
Message-ID: <vv-7i2dHYAle20hphS8ZkNjB6SSzfvJZrCogOEX_rNk=.c37260d1-b3d0-45bf-b6fe-b66b761cf3e4@github.com>

> Hi all,
> 
> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
> 
> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
> 
> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
> 
> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
> 
> Change has been verified locally, test-fix only, no risk.

SendaoYan 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 three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jbs8362087
 - Add synchronized lock for addClassOptions
 - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26605/files
  - new: https://git.openjdk.org/jdk/pull/26605/files/284bda62..2e9df8dc

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

  Stats: 258023 lines in 3950 files changed: 190181 ins; 45945 del; 21897 mod
  Patch: https://git.openjdk.org/jdk/pull/26605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26605/head:pull/26605

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

From alanb at openjdk.org  Fri Sep 26 06:01:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:01:19 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v2]
In-Reply-To: <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <US4moEsKhodY4clh1ryTHdveFMt6nvjYX_v7xDzxvWU=.0620f6d4-7576-454b-bbd8-570ee07b023b@github.com>
 <tLlwGcnnK-oXp2YZ2yiwfWPnjiD_ThblpjAvYRW5LwI=.62d9d48b-3a4f-49bd-ac8c-199706e6fbfc@github.com>
 <J1Ks6v9mYoZZuzSctlKcIVrULVN2Xs-OmmmnHyvrFik=.24d812e8-c03c-4b42-bf6b-5450eb85b783@github.com>
 <bgIzt7IBbf8_HC5yDFSh2vlxWdyECYquUF43eEdmvac=.0d5dc359-c8b6-40ed-b06c-d4536e1461e6@github.com>
Message-ID: <4XBBUGAlktyMI3A2agyrCjlY4IKtxp1eUX8_YWSp_gI=.f9f1e32b-1a3c-4265-bafb-767211e171b5@github.com>

On Thu, 25 Sep 2025 19:08:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The original "contain" was correct. Alternatively:
>>> Returns true if lines is a plain text thread dump containing the given text.
>
> Well.. this was Alan's request to update the comment.
> To me original comment was clear and correct.
> @AlanBateman , what do you prefer to see here:
> - Returns true if lines of a plain text thread dump contain the given text. (original)
> - Returns true if lines of a plain text thread dump is containing the given text.
> - Returns true if lines is a plain text thread dump containing the given text.

Apologies, it was a typo in a separate branch used for prototype. So ignore my comment, I think left the existing comment on the test method as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2380945985

From dholmes at openjdk.org  Fri Sep 26 06:17:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 Sep 2025 06:17:28 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
Message-ID: <Dzz5arqrg_flpzwNUpFue4GGnkSC1cSY_m7sWDRGiHY=.e190cf5d-3238-437b-b1e2-1407b516490b@github.com>

On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev 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 JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

Thanks for the update. Nothing further from me.

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

PR Review: https://git.openjdk.org/jdk/pull/25824#pullrequestreview-3270306288

From alanb at openjdk.org  Fri Sep 26 06:31:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Sep 2025 06:31:15 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <99K6laRc0VAmj4SpVQUMyFFqGNa2pRr3s-b6atp8jzE=.fd9bb67e-5902-4bfc-aef5-2e8b9c256581@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Aside from the issues with the method comments in the DumpThreads test, I think this is okay and I don't have other comments.

As per the discussion in the JBS issue, it's still a bit icky to read this field when all access is plain access, but it may be useful for diagnosing hangs and deadlocks.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270352643

From azeller at openjdk.org  Fri Sep 26 07:20:15 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 26 Sep 2025 07:20:15 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic
 fails on non CDS platforms/builds after JDK-8362561
In-Reply-To: <Lsx6wdeUVNEAGnZiS0JzblfCbA8VIt7j33fvIfpASss=.3747acfd-5a9a-4f4f-b3fb-c120ad3359c5@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
 <Lsx6wdeUVNEAGnZiS0JzblfCbA8VIt7j33fvIfpASss=.3747acfd-5a9a-4f4f-b3fb-c120ad3359c5@github.com>
Message-ID: <DgBM-gXwMcRqV0mPkI4alhCidB7EaU2idmh45I9hLxQ=.baa301dc-ae26-48cd-b6e5-f71a3dfb03ef@github.com>

On Thu, 25 Sep 2025 10:51:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
>> The new subtest test misses the @requires that exists in the other subtests.
>
> Marked as reviewed by mbaesken (Reviewer).

@MBaesken, @shipilev and @iklam : Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27484#issuecomment-3337099942

From duke at openjdk.org  Fri Sep 26 07:20:17 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 07:20:17 GMT
Subject: RFR: 8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic
 fails on non CDS platforms/builds after JDK-8362561
In-Reply-To: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
Message-ID: <Uj8Rp9szQovP1VmuMyMEESexrv075NasmbV-7-JBXfs=.8c78e823-3200-4a1b-b2cc-67695c68e328@github.com>

On Thu, 25 Sep 2025 08:09:07 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
> The new subtest test misses the @requires that exists in the other subtests.

@ArnoZeller 
Your change (at version 411870091403b78c0686e55ba8c6d3108e5a3af5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27484#issuecomment-3337105844

From sspitsyn at openjdk.org  Fri Sep 26 07:24:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 07:24:26 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
Message-ID: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>

On Thu, 25 Sep 2025 19:40:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Just one simple comment update is still needed. Otherwise, it is good.

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:

> 686: 
> 687:     /**
> 688:      * Returns true if lines of a plain text thread dump containing the given text.

Nit: This still needs to be reverted back.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3270528351
PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2381135179

From azeller at openjdk.org  Fri Sep 26 07:50:29 2025
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 26 Sep 2025 07:50:29 GMT
Subject: Integrated: 8368616:
 runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails on non CDS
 platforms/builds after JDK-8362561
In-Reply-To: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
References: <Ga5AVhUwLd_vRryR_6r09YLzdZN8EjAj4NcEhUSu8TA=.10dd3114-29dc-4263-a93c-56bd461b47aa@github.com>
Message-ID: <URxntI2cqMIv4LJIamIbn4Oh5zYpuF_25YXA47T0OTU=.acc2cfd1-a2cc-4dad-ac2d-518b5cd26307@github.com>

On Thu, 25 Sep 2025 08:09:07 GMT, Arno Zeller <azeller at openjdk.org> wrote:

> The new subtest runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails after [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) on platforms without CDS or in builds without CDS.
> The new subtest test misses the @requires that exists in the other subtests.

This pull request has now been integrated.

Changeset: b90799c0
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b90799c0e92468b341235989f731bb93e2741a77
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails on non CDS platforms/builds after JDK-8362561

Reviewed-by: mbaesken, shade, iklam

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

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

From aboldtch at openjdk.org  Fri Sep 26 09:13:27 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 26 Sep 2025 09:13:27 GMT
Subject: RFR: 8368754: runtime/cds/appcds/SignedJar.java log regex is to strict
Message-ID: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>

Any logging which gets enabled (via `-verbose:class` which the test uses, or externally from JTREG) and logs before the line this test is checking for with a tag set which is longer than `class,load` makes the test fail.
Example:
Test expects: 
 * `"[class,load] Hello source: [...]"`
 
What it gets when logging with `class,unload` prior to this specific log line: 
 * `"[class,load ] Hello source: [...]"`

I suggest we simply allow for any whitespace after the log tags and before the `.`. Unclear why we use `.` and not `]`. But think it works just as well.

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

Commit messages:
 - 8368754: runtime/cds/appcds/SignedJar.java log regex is to strict

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

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

From jsjolen at openjdk.org  Fri Sep 26 12:17:18 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 26 Sep 2025 12:17:18 GMT
Subject: RFR: 8358597: [asan] Buffer overflow in
 ArchiveBuilder::make_shallow_copy with Symbols
In-Reply-To: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>
References: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>
Message-ID: <BdWJWrb5eD5yPUrnUYT9mpravHwlnzLERjLaykT0tsc=.585e6987-3e32-4c43-8ba8-fb9c8f05671f@github.com>

On Fri, 26 Sep 2025 02:32:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan.
> 
> The fix is to copy the exact number of bytes for Symbols.
> 
> Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable.

Marked as reviewed by jsjolen (Reviewer).

Hi Ioi,

This change looks like it solves the bug. I was thinking about this, it seems that we're already doing some special-casing when looking at `MSO::ClassType`. Perhaps it would be good to have all special-cases at the top and have them 'hug' together? Below is a variant of your fix that does that. AFAIU it's "well-known" that AOTCache zeroes out all memory allocated, so we don't need to mention that in the comment.

```c++
  address src = src_info->source_addr();
  int bytes_needed = src_info->size_in_bytes();
  char* dest;
  char* oldtop;
  char* newtop;

  oldtop = dump_region->top();

  if (src_info->msotype() == MetaspaceObj::ClassType) {
    // Allocate space for a pointer directly in front of the future InstanceKlass, so
    // we can do a quick lookup from InstanceKlass* -> RunTimeClassInfo*
    // without building another hashtable. See RunTimeClassInfo::get_for()
    // in systemDictionaryShared.cpp.
    Klass* klass = (Klass*)src;
    if (klass->is_instance_klass()) {
      SystemDictionaryShared::validate_before_archiving(InstanceKlass::cast(klass));
      bytes_needed += sizeof(address);
    }
    // Allocate space for the future InstanceKlass with proper alignment
    const size_t alignment =
#ifdef _LP64
      UseCompressedClassPointers ?
        nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift()) :
        SharedSpaceObjectAlignment;
#else
      SharedSpaceObjectAlignment;
#endif
  } else if (src_info->msotype() == MetaspaceObj::SymbolType) {
    // Symbols may be allocated by using AllocateHeap, so their sizes
    // may be less than size_in_bytes() indicates.
    bytes_needed = ((Symbol*)src)->byte_size();
  } else {
    // All other cases need no special-handling.
  }
  dest = dump_region->allocate(bytes_needed);
  newtop = dump_region->top();

  memcpy(dest, src, bytes_needed);

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

PR Review: https://git.openjdk.org/jdk/pull/27508#pullrequestreview-3271981634
PR Comment: https://git.openjdk.org/jdk/pull/27508#issuecomment-3338391828

From mli at openjdk.org  Fri Sep 26 12:32:58 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 26 Sep 2025 12:32:58 GMT
Subject: RFR: 8367981: Update CompactHashtable [v5]
In-Reply-To: <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
Message-ID: <NUGXKD7CV6JSJAmXXOj2nh5BSvJHArxzbEjZedw2Ylk=.8219c106-e9f9-4331-b427-7b3854281723@github.com>

On Wed, 24 Sep 2025 08:34:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> Also update some code (names) related to CompactHashtable.
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename 2

Hey, is someone available to have another look? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27360#issuecomment-3338488891

From duke at openjdk.org  Fri Sep 26 13:53:56 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 13:53:56 GMT
Subject: RFR: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <rvY54xHEbCYThmKXZPbepopayc2mj1tzNiynO-oINMY=.20cbe17f-46ea-4a92-90f1-f44cda817262@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27489#issuecomment-3338831250

From jwaters at openjdk.org  Fri Sep 26 16:34:21 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 26 Sep 2025 16:34:21 GMT
Subject: RFR: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <BjKZigdC9CBIrwWysNVR2AeQ8CSJMgXOOHazESZSLTA=.83895d04-a05c-46fc-a7b7-088e2c57896f@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

HotSpot looks good. Please wait for the reviewers of the other non HotSpot parts to approve before integrating however.

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27489#pullrequestreview-3272985248

From iklam at openjdk.org  Fri Sep 26 16:38:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 16:38:28 GMT
Subject: RFR: 8368754: runtime/cds/appcds/SignedJar.java log regex is to
 strict
In-Reply-To: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
References: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
Message-ID: <pFNF3bWpVPa9qgVakqQPlPdyx64exE-x5FcHZXIHAz0=.cf739ba9-bac6-40b8-a672-90ef77cc45cb@github.com>

On Fri, 26 Sep 2025 09:06:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Any logging which gets enabled (via `-verbose:class` which the test uses, or externally from JTREG) and logs before the line this test is checking for with a tag set which is longer than `class,load` makes the test fail.
> Example:
> Test expects: 
>  * `"[class,load] Hello source: [...]"`
>  
> What it gets when logging with `class,unload` prior to this specific log line: 
>  * `"[class,load ] Hello source: [...]"`
> 
> I suggest we simply allow for any whitespace after the log tags and before the `.`. Unclear why we use `.` and not `]`. But think it works just as well.

Looks good to me. The original code used `.` to avoid quoating the `[` character.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27517#pullrequestreview-3273004033

From iklam at openjdk.org  Fri Sep 26 16:43:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 16:43:28 GMT
Subject: RFR: 8358597: [asan] Buffer overflow in
 ArchiveBuilder::make_shallow_copy with Symbols [v2]
In-Reply-To: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>
References: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>
Message-ID: <7izVzVUp-9d3lcGnR_eGA0Y-7KcWVkPMudGMiE2u4VM=.421d5d1b-6674-4a82-9956-6649fdb025be@github.com>

> The bug: when Symbols are copied into the dynamic CDS archive, extra padding bytes may be copied, which triggers "buffer overflow" errors in asan.
> 
> The fix is to copy the exact number of bytes for Symbols.
> 
> Since `ArchiveBuilder::make_shallow_copy()` deals with different alignments and sizes, I renamed the variables and added comments/asserts to make the code more readable.

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 four additional commits since the last revision:

 - @jdksjolen comments -- simplified patch
 - Merge branch 'master' into 8358597-asan-heap-buffer-flow-archive-builder-make-shallow-copy
 - More clean up
 - 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27508/files
  - new: https://git.openjdk.org/jdk/pull/27508/files/1a13512f..12d41aa5

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

  Stats: 5872 lines in 156 files changed: 3331 ins; 1891 del; 650 mod
  Patch: https://git.openjdk.org/jdk/pull/27508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27508/head:pull/27508

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

From iklam at openjdk.org  Fri Sep 26 16:45:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 16:45:33 GMT
Subject: RFR: 8358597: [asan] Buffer overflow in
 ArchiveBuilder::make_shallow_copy with Symbols
In-Reply-To: <BdWJWrb5eD5yPUrnUYT9mpravHwlnzLERjLaykT0tsc=.585e6987-3e32-4c43-8ba8-fb9c8f05671f@github.com>
References: <RWRhgNhqhYB5fczEfA0x2EAmqOdT5LnMLkbJzH2jkwI=.7d3b9a6d-4132-42ce-864b-96284a89b1e9@github.com>
 <BdWJWrb5eD5yPUrnUYT9mpravHwlnzLERjLaykT0tsc=.585e6987-3e32-4c43-8ba8-fb9c8f05671f@github.com>
Message-ID: <oL8G9EmeGFvBsCWqXTbiXTuqny_jBMQd5EeiimDx_sg=.47592ef4-22a6-44f1-84cc-f10a7e7d1e6e@github.com>

On Fri, 26 Sep 2025 12:13:47 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi Ioi,
> 
> This change looks like it solves the bug. I was thinking about this, it seems that we're already doing some special-casing when looking at `MSO::ClassType`. Perhaps it would be good to have all special-cases at the top and have them 'hug' together? Below is a variant of your fix that does that. AFAIU it's "well-known" that AOTCache zeroes out all memory allocated, so we don't need to mention that in the comment.
> 
> ```c++
>   address src = src_info->source_addr();
>   int bytes_needed = src_info->size_in_bytes();
>   char* dest;
>   char* oldtop;
>   char* newtop;
> 
>   oldtop = dump_region->top();
> 
>   if (src_info->msotype() == MetaspaceObj::ClassType) {
>     // Allocate space for a pointer directly in front of the future InstanceKlass, so
>     // we can do a quick lookup from InstanceKlass* -> RunTimeClassInfo*
>     // without building another hashtable. See RunTimeClassInfo::get_for()
>     // in systemDictionaryShared.cpp.
>     Klass* klass = (Klass*)src;
>     if (klass->is_instance_klass()) {
>       SystemDictionaryShared::validate_before_archiving(InstanceKlass::cast(klass));
>       bytes_needed += sizeof(address);
>     }
>     // Allocate space for the future InstanceKlass with proper alignment
>     const size_t alignment =
> #ifdef _LP64
>       UseCompressedClassPointers ?
>         nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift()) :
>         SharedSpaceObjectAlignment;
> #else
>       SharedSpaceObjectAlignment;
> #endif
>   } else if (src_info->msotype() == MetaspaceObj::SymbolType) {
>     // Symbols may be allocated by using AllocateHeap, so their sizes
>     // may be less than size_in_bytes() indicates.
>     bytes_needed = ((Symbol*)src)->byte_size();
>   } else {
>     // All other cases need no special-handling.
>   }
>   dest = dump_region->allocate(bytes_needed);
>   newtop = dump_region->top();
> 
>   memcpy(dest, src, bytes_needed);
> ```

Thanks for the suggestion. It's easier to understand so less comment is needed :-)

I've moved around the code as you suggested. I had to update the alignment calculation for klasses as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27508#issuecomment-3339563555

From amenkov at openjdk.org  Fri Sep 26 19:05:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:32 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  reverted comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27457/files
  - new: https://git.openjdk.org/jdk/pull/27457/files/bc664ef4..f588a6da

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

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

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

From sspitsyn at openjdk.org  Fri Sep 26 19:19:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Sep 2025 19:19:24 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v6]
In-Reply-To: <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <Y5LHDlWvY2IGR3AsGOUvLk9d-QVnCTnf-GAw5grSpJ4=.6a1a8f6d-b4f5-49c3-bca0-ff7b17d9833f@github.com>
Message-ID: <etXxraj3IIaQ0VLwwgB2u-uGCGFfopkpjrR7hQz6lgQ=.e18358d0-5f8a-447b-9ec5-716ee2d1898b@github.com>

On Fri, 26 Sep 2025 19:05:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
>> 
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27457#pullrequestreview-3273600528

From amenkov at openjdk.org  Fri Sep 26 19:05:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 19:05:35 GMT
Subject: RFR: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file [v5]
In-Reply-To: <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
 <EmsLmHEnO0URPHueoABRk4RW2t5vy-UDC4LzyFs_zjo=.1df4058a-3c35-427c-afff-0fbad4e5342c@github.com>
 <qV_ePYy93VPsUshcIc9P5SribMETeShF7BmyVQN1kbA=.05f17d3b-31df-4f06-9ba8-93a7bf92323d@github.com>
Message-ID: <PipknE4_c6ETRhMkBPMxUhl3braANS3e4xPFDpAv8DQ=.91df2314-f53f-4600-bc54-5f0f4e31a773@github.com>

On Fri, 26 Sep 2025 07:20:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 688:
> 
>> 686: 
>> 687:     /**
>> 688:      * Returns true if lines of a plain text thread dump containing the given text.
> 
> Nit: This still needs to be reverted back.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27457#discussion_r2383242806

From amenkov at openjdk.org  Fri Sep 26 20:52:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 20:52:40 GMT
Subject: Integrated: 8365057: Add support for java.util.concurrent lock
 information to Thread.dump_to_file
In-Reply-To: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
References: <4y71pNw79LMRD0ShbXn9KEEVaCwWTK3dvJggrFlyQII=.39284d89-e29e-480b-bd0b-109087d6d6fc@github.com>
Message-ID: <QjOZIt0Ydlb7DmgAItQeuf83Q9aOzUqgELPHvciMr44=.b577ef3a-2f60-4444-8600-d1d5025cb542@github.com>

On Tue, 23 Sep 2025 20:22:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates `jcmd Thread.dump_to_file`/`HotSpotDiagnosticMXBean.dumpThreads` implementation to report thread which owns parkBlocker.
> 
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: cedc0117
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cedc0117ac36243cc240e8ab6adb3c78af4055fc
Stats:     78 lines in 6 files changed: 65 ins; 0 del; 13 mod

8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file

Co-authored-by: Alex Menkov <amenkov at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: sspitsyn, alanb

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

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

From fandreuzzi at openjdk.org  Sun Sep 28 10:52:17 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sun, 28 Sep 2025 10:52:17 GMT
Subject: RFR: 8368818: Deduplicate dtrace macros in objectMonitor and
 synchronizer
Message-ID: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>

I propose to move the following macros and constants definition to `objectMonitor.hpp`:

DTRACE_MONITOR_PROBE_COMMON
DTRACE_MONITOR_WAIT_PROBE
DTRACE_MONITOR_PROBE
HOTSPOT_MONITOR_notify
HOTSPOT_MONITOR_notifyAll

They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.

Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.

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

Commit messages:
 - cc
 - dedup

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

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

From dholmes at openjdk.org  Mon Sep 29 02:38:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Sep 2025 02:38:12 GMT
Subject: RFR: 8368754: runtime/cds/appcds/SignedJar.java log regex is to
 strict
In-Reply-To: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
References: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
Message-ID: <P4NIjZDEScvnS7zhwpTGo4BTZRVR1ntqZcW1q9HlRvg=.30aaf7c1-02b0-42e7-87a0-6f38a5c74f66@github.com>

On Fri, 26 Sep 2025 09:06:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Any logging which gets enabled (via `-verbose:class` which the test uses, or externally from JTREG) and logs before the line this test is checking for with a tag set which is longer than `class,load` makes the test fail.
> Example:
> Test expects: 
>  * `"[class,load] Hello source: [...]"`
>  
> What it gets when logging with `class,unload` prior to this specific log line: 
>  * `"[class,load ] Hello source: [...]"`
> 
> I suggest we simply allow for any whitespace after the log tags and before the `.`. Unclear why we use `.` and not `]`. But think it works just as well.

LGTM2.

FWIW using . instead of [ is rather obscure for the casual reader.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27517#pullrequestreview-3277694540

From dholmes at openjdk.org  Mon Sep 29 04:37:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Sep 2025 04:37:16 GMT
Subject: RFR: 8368818: Remove duplicate dtrace macros
In-Reply-To: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
Message-ID: <_JuiMxlqZky4AldJo5eeB_hJPXDnmAZLcL2STvH_U4o=.37430d22-dff7-4d33-9f6a-b09fbb08f3b7@github.com>

On Sun, 28 Sep 2025 10:45:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I propose to move the following macros and constants definition to `objectMonitor.hpp`:
> 
> DTRACE_MONITOR_PROBE_COMMON
> DTRACE_MONITOR_WAIT_PROBE
> DTRACE_MONITOR_PROBE
> HOTSPOT_MONITOR_notify
> HOTSPOT_MONITOR_notifyAll
> 
> They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.
> 
> Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.

The duplication has existed since `objectMonitor.cpp` was created from content previously in `synchronizer.cpp` back in Java 7 and 6u25 days. All of the DTrace probe macros are defined in .cpp files. Putting these in the header file so they can be shared is a notional convenience but they are not really part of any interface that should be exposed to all code that includes the header. This is not code that gets updated so there is no maintenance effort that I can see. I'm inclined to just leave this alone.

Also `objectMonitor.hpp` should now be including all the headers needed to actually compile these macros - which also seems undesirable.

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

PR Comment: https://git.openjdk.org/jdk/pull/27538#issuecomment-3344827263
PR Comment: https://git.openjdk.org/jdk/pull/27538#issuecomment-3344831961

From aboldtch at openjdk.org  Mon Sep 29 05:22:23 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 29 Sep 2025 05:22:23 GMT
Subject: RFR: 8368754: runtime/cds/appcds/SignedJar.java log regex is too
 strict
In-Reply-To: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
References: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
Message-ID: <z61EYFD9KniGlJ4j-q5gBHQBJDkLdwzjdtMxP4zFL-Q=.cee5d3ce-ebdf-447f-9995-b3e7ee5854c5@github.com>

On Fri, 26 Sep 2025 09:06:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Any logging which gets enabled (via `-verbose:class` which the test uses, or externally from JTREG) and logs before the line this test is checking for with a tag set which is longer than `class,load` makes the test fail.
> Example:
> Test expects: 
>  * `"[class,load] Hello source: [...]"`
>  
> What it gets when logging with `class,unload` prior to this specific log line: 
>  * `"[class,load ] Hello source: [...]"`
> 
> I suggest we simply allow for any whitespace after the log tags and before the `.`. Unclear why we use `.` and not `]`. But think it works just as well.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27517#issuecomment-3344966581

From aboldtch at openjdk.org  Mon Sep 29 05:22:23 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 29 Sep 2025 05:22:23 GMT
Subject: Integrated: 8368754: runtime/cds/appcds/SignedJar.java log regex is
 too strict
In-Reply-To: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
References: <F2cz7qvX2H3a5SUd67RIQvgKV81jel6BQmWpNfBPePY=.f7cb104a-8573-4a17-b560-8e50ba3a1177@github.com>
Message-ID: <SkaRmYbJ25K6WiRsWJ3phDhGqU4_J01ftpjwWwLEC0g=.9d83fbe3-644a-4143-a4e6-9fc70713ba5d@github.com>

On Fri, 26 Sep 2025 09:06:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Any logging which gets enabled (via `-verbose:class` which the test uses, or externally from JTREG) and logs before the line this test is checking for with a tag set which is longer than `class,load` makes the test fail.
> Example:
> Test expects: 
>  * `"[class,load] Hello source: [...]"`
>  
> What it gets when logging with `class,unload` prior to this specific log line: 
>  * `"[class,load ] Hello source: [...]"`
> 
> I suggest we simply allow for any whitespace after the log tags and before the `.`. Unclear why we use `.` and not `]`. But think it works just as well.

This pull request has now been integrated.

Changeset: e19ec6f7
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e19ec6f785e889d254b15c5ef2e801152c59c948
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8368754: runtime/cds/appcds/SignedJar.java log regex is too strict

Reviewed-by: iklam, dholmes

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

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

From azafari at openjdk.org  Mon Sep 29 08:41:31 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 29 Sep 2025 08:41:31 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree [v3]
In-Reply-To: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
Message-ID: <b1PWnrHfueQyrNF98EdW3ZixuTTeDGd1-xa5dUtyWec=.9faf5f5f-c50d-412b-baab-5c692907c3d0@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 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 three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into _8342730_summary_diff_ref
 - better naming for diff
 - 8342730: Get rid of SummaryDiff in VMATree

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26761/files
  - new: https://git.openjdk.org/jdk/pull/26761/files/9b53507d..5178e1bb

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

  Stats: 230268 lines in 3499 files changed: 173245 ins; 37169 del; 19854 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  Mon Sep 29 09:11:52 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 29 Sep 2025 09:11:52 GMT
Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with
 ASAN
In-Reply-To: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>
References: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>
Message-ID: <72esqYRMYtUda_kbK20paCvNSGHudgG7SVlu2_UQVH0=.69dc89ef-68a3-4996-b31a-e060e02fc3db@github.com>

On Fri, 12 Sep 2025 07:54:05 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> 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

@tstuefe, would you please give your review/feedback on this PR. TIA.

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

PR Comment: https://git.openjdk.org/jdk/pull/27248#issuecomment-3345842636

From azafari at openjdk.org  Mon Sep 29 09:37:44 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 29 Sep 2025 09:37:44 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v4]
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <9veNrm3XyhTkEtGfzE9lfrra9Rocvo7gVKBVCcvPbuM=.9b80a355-244a-41e7-a354-1b0e91103bc2@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 seven commits:

 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - master merge fix
 - 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=03
  Stats: 194 lines in 12 files changed: 39 ins; 93 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 fandreuzzi at openjdk.org  Mon Sep 29 14:10:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 29 Sep 2025 14:10:02 GMT
Subject: RFR: 8368818: Remove duplicate dtrace macros
In-Reply-To: <_JuiMxlqZky4AldJo5eeB_hJPXDnmAZLcL2STvH_U4o=.37430d22-dff7-4d33-9f6a-b09fbb08f3b7@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
 <_JuiMxlqZky4AldJo5eeB_hJPXDnmAZLcL2STvH_U4o=.37430d22-dff7-4d33-9f6a-b09fbb08f3b7@github.com>
Message-ID: <uj73leCYLz-E-Dj5-Mxsn5E67Q0eY40pDsgsgmdJ_q8=.e857c238-7851-4a75-a3a7-0ac37966f380@github.com>

On Mon, 29 Sep 2025 04:34:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I propose to move the following macros and constants definition to `objectMonitor.hpp`:
>> 
>> DTRACE_MONITOR_PROBE_COMMON
>> DTRACE_MONITOR_WAIT_PROBE
>> DTRACE_MONITOR_PROBE
>> HOTSPOT_MONITOR_notify
>> HOTSPOT_MONITOR_notifyAll
>> 
>> They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.
>> 
>> Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.
>
> Also `objectMonitor.hpp` should now be including all the headers needed to actually compile these macros - which also seems undesirable.

Hi @dholmes-ora, thanks for the feedback. Makes sense to me, I'll close the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27538#issuecomment-3347182744

From fandreuzzi at openjdk.org  Mon Sep 29 14:10:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 29 Sep 2025 14:10:04 GMT
Subject: Withdrawn: 8368818: Remove duplicate dtrace macros
In-Reply-To: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
Message-ID: <Jc7d6UalCMXjBtIaLlUKIa_xprI8gvotBRi7dWqEvcU=.a5656c8f-b647-4039-be71-0e54238e292a@github.com>

On Sun, 28 Sep 2025 10:45:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I propose to move the following macros and constants definition to `objectMonitor.hpp`:
> 
> DTRACE_MONITOR_PROBE_COMMON
> DTRACE_MONITOR_WAIT_PROBE
> DTRACE_MONITOR_PROBE
> HOTSPOT_MONITOR_notify
> HOTSPOT_MONITOR_notifyAll
> 
> They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.
> 
> Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.

This pull request has been closed without being integrated.

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

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

From matsaave at openjdk.org  Mon Sep 29 14:46:24 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 29 Sep 2025 14:46:24 GMT
Subject: RFR: 8367981: Update CompactHashtable for readability [v5]
In-Reply-To: <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
Message-ID: <uBmExFogRAu3iXDuanXBA_AnMTN2nI4GZdSReRRVTjs=.7786fc55-76cb-4c42-aba9-184f2fae8b5e@github.com>

On Wed, 24 Sep 2025 08:34:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> 
>> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
>> As the related classes are used in more and more scenarios, it's helpful to update the comments.
>> 
>> To improve readability (of both the source code and the comments), we should also rename some of the field/parameters to distinguish between the type V (the "value " stored inside the table; it could be a 64-bit pointer) vs "encoded value" (the 32-bit representation of V in the CompactHashtable storage).
>> 
>> Thanks
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename 2

LGTM!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27360#pullrequestreview-3280249043

From coleenp at openjdk.org  Mon Sep 29 15:08:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Sep 2025 15:08:53 GMT
Subject: RFR: 8368818: Remove duplicate dtrace macros
In-Reply-To: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
Message-ID: <O8IHlJJQNRrrtcc_N5BSjR2Y30EHaBVfX1ccJUKxlZI=.c0882ed2-ad31-46d6-afd1-e0cba6b218e0@github.com>

On Sun, 28 Sep 2025 10:45:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> I propose to move the following macros and constants definition to `objectMonitor.hpp`:
> 
> DTRACE_MONITOR_PROBE_COMMON
> DTRACE_MONITOR_WAIT_PROBE
> DTRACE_MONITOR_PROBE
> HOTSPOT_MONITOR_notify
> HOTSPOT_MONITOR_notifyAll
> 
> They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.
> 
> Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.

src/hotspot/share/runtime/synchronizer.cpp line 218:

> 216: // TODO-FIXME: probes should not fire when caller is _blocked.  assert() accordingly.
> 217: 
> 218: #define DTRACE_MONITOR_PROBE_COMMON(obj, thread)                           \

I agree that these shouldn't be in objectMonitor.hpp file.  With Legacy locking removed, are these still needed in synchronizer.cpp ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27538#discussion_r2388321042

From coleenp at openjdk.org  Mon Sep 29 15:08:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Sep 2025 15:08:54 GMT
Subject: RFR: 8368818: Remove duplicate dtrace macros
In-Reply-To: <O8IHlJJQNRrrtcc_N5BSjR2Y30EHaBVfX1ccJUKxlZI=.c0882ed2-ad31-46d6-afd1-e0cba6b218e0@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
 <O8IHlJJQNRrrtcc_N5BSjR2Y30EHaBVfX1ccJUKxlZI=.c0882ed2-ad31-46d6-afd1-e0cba6b218e0@github.com>
Message-ID: <7dxS3mz2QrOY6SJUIkcyLoGBF_R3_6Y-gPSGgPhZc5M=.b82950ec-f725-4ac0-8531-06787c103b8c@github.com>

On Mon, 29 Sep 2025 15:05:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I propose to move the following macros and constants definition to `objectMonitor.hpp`:
>> 
>> DTRACE_MONITOR_PROBE_COMMON
>> DTRACE_MONITOR_WAIT_PROBE
>> DTRACE_MONITOR_PROBE
>> HOTSPOT_MONITOR_notify
>> HOTSPOT_MONITOR_notifyAll
>> 
>> They are defined both in `objectMonitor.cpp` and `synchronizer.cpp`.
>> 
>> Passes tier1 (fastdebug) with `--enable-jvm-feature-dtrace`.
>
> src/hotspot/share/runtime/synchronizer.cpp line 218:
> 
>> 216: // TODO-FIXME: probes should not fire when caller is _blocked.  assert() accordingly.
>> 217: 
>> 218: #define DTRACE_MONITOR_PROBE_COMMON(obj, thread)                           \
> 
> I agree that these shouldn't be in objectMonitor.hpp file.  With Legacy locking removed, are these still needed in synchronizer.cpp ?

It would be nice to understand why these are used in general.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27538#discussion_r2388322712

From jsjolen at openjdk.org  Mon Sep 29 16:43:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 Sep 2025 16:43:45 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v4]
In-Reply-To: <9veNrm3XyhTkEtGfzE9lfrra9Rocvo7gVKBVCcvPbuM=.9b80a355-244a-41e7-a354-1b0e91103bc2@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <9veNrm3XyhTkEtGfzE9lfrra9Rocvo7gVKBVCcvPbuM=.9b80a355-244a-41e7-a354-1b0e91103bc2@github.com>
Message-ID: <FiDurmvpZZP9Ubnh4kJYcFQvzpGM14JhHCJgMfXwOYw=.3a5c6d7d-c441-4145-bf1f-ffdd57d2f68d@github.com>

On Mon, 29 Sep 2025 09:37:44 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
>
> Afshin Zafari 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 remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - master merge fix
>  - 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

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 196:

> 194:  */
> 195: class VirtualMemoryRegion {
> 196:  private:

Style, pre-existing: Remove this private as it's private by default at the start.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 200:

> 198:   size_t          _size;
> 199:   MemTag          _mem_tag;
> 200:   NativeCallStack _reserved_stack, _committed_stack;

Style: Please separate out these into two declarations on two lines.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 236:

> 234: 
> 235:   inline bool contain_address(address addr) const {
> 236:     assert(is_valid(), "snaity");

"sanity"

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 244:

> 242:     assert(sz > 0, "Invalid size");
> 243:     assert(size() > 0, "Invalid size");
> 244:     assert(is_valid(), "snaity");

"sanity"

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 265:

> 263:   inline bool equals(const VirtualMemoryRegion& rgn) const {
> 264:     return compare(rgn) == 0;
> 265:   }

Is this used?

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 273:

> 271:   bool is_valid() const { return base() != nullptr && size() != 0;}
> 272: 
> 273:   inline void  set_reserved_call_stack(const NativeCallStack& stack) { _reserved_stack = stack; }

Is this used? Doesn't it make more sense for these values to be constant and the VMR to be an immutable object (in essence).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388569129
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388582133
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388570928
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388571464
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388573486
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2388575968

From jsjolen at openjdk.org  Mon Sep 29 16:59:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 Sep 2025 16:59:10 GMT
Subject: RFR: 8368885: NMT CommandLine tests can check for error better
Message-ID: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>

We can check for more specific error text when running the command line tests, the current 'error' string check misses NMT parsing succeeding but NMT initialization failure.

We also fix the indentation of the test files, let's use 4 spaces in the Java source files.

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

Commit messages:
 - Check for more specific issues

Changes: https://git.openjdk.org/jdk/pull/27554/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368885
  Stats: 22 lines in 2 files changed: 2 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27554/head:pull/27554

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

From azafari at openjdk.org  Mon Sep 29 18:52:32 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 29 Sep 2025 18:52:32 GMT
Subject: RFR: 8366884: NMT fails with MallocLimit: reached category
 "mtCompiler" limit
In-Reply-To: <4QMdmn4CFbutMqIe78YdUQGBj3rLVyyXEkt5Ajf1B0k=.516427fd-4475-49dd-be22-ab17977d10ac@github.com>
References: <bs7bvViPRH0l5vATEy7vssHhJ1Rm6GEhbBm3Fs53CH0=.c6f7cc50-0883-4115-a770-6c9b1c305788@github.com>
 <4QMdmn4CFbutMqIe78YdUQGBj3rLVyyXEkt5Ajf1B0k=.516427fd-4475-49dd-be22-ab17977d10ac@github.com>
Message-ID: <gE7scHcPrwg-jAfTVM-EZepGQFUMd1fliQ53Gg-dxBg=.94143907-05ed-4d5d-a03f-5135fe03eaef@github.com>

On Thu, 18 Sep 2025 09:52:09 GMT, Johan Sj?len <jsjolen 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.
>
> OK, thanks

@jdksjolen and @Arraying , thanks for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27246#issuecomment-3345660003

From azafari at openjdk.org  Mon Sep 29 19:28:33 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 29 Sep 2025 19:28:33 GMT
Subject: Integrated: 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: <cu3PM8V7ZqcpaXSuHVlOcN3RqQwCqaCVfOQaXW4eY2k=.08ee5bf8-12f2-468f-be70-cc5b1ef1f3c5@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.

This pull request has now been integrated.

Changeset: 2f29b3f2
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f29b3f24a31bbe58d9c3433d46b69c16002694b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8366884: NMT fails with MallocLimit: reached category "mtCompiler" limit

Reviewed-by: phubner, jsjolen

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

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

From kbarrett at openjdk.org  Tue Sep 30 03:01:58 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 30 Sep 2025 03:01:58 GMT
Subject: RFR: 8368817: Convert JDK_Version::to_string to use stringStream
 instead of jio_snprintf-chain
Message-ID: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com>

Please review this change to JDK_Version::to_string to use stringStream to
accumulate the version string in the buffer, rather than using jio_snprintf to
write the various pieces.

Testing: mach5 tier1
Locally manually examined result of JDK_Version for builds configured with
different values for various version parameters.

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

Commit messages:
 - JDK_Version::to_string

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

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

From stuefe at openjdk.org  Tue Sep 30 05:09:46 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 30 Sep 2025 05:09:46 GMT
Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with
 ASAN
In-Reply-To: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>
References: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>
Message-ID: <TSTrYwxEuyO5p7amac-O3Jn_dPkca__jzPwKqHgo7ng=.d9926853-d0f4-4726-804a-4bf2c7b8feed@github.com>

On Fri, 12 Sep 2025 07:54:05 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> 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

Sorry for the delay, this fell through the cracks somehow. Good. Thanks!

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27248#pullrequestreview-3282603014

From jpai at openjdk.org  Tue Sep 30 06:55:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Sep 2025 06:55:49 GMT
Subject: RFR: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <-AtApQjIshlnieD15eDe-CktLxAG14eDbk8USBlQ0P0=.dbf5e726-ba74-4ba3-aeb7-97dd820c130b@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

This looks good and trivial to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27489#pullrequestreview-3282862820

From dholmes at openjdk.org  Tue Sep 30 07:20:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Sep 2025 07:20:16 GMT
Subject: RFR: 8368818: Remove duplicate dtrace macros
In-Reply-To: <7dxS3mz2QrOY6SJUIkcyLoGBF_R3_6Y-gPSGgPhZc5M=.b82950ec-f725-4ac0-8531-06787c103b8c@github.com>
References: <Z5Fvbf9Rm2oQtXr9yk48c8BR2wfpBbxOCWP3CPVVK0k=.4708c8f9-e931-45c9-9792-fc0b4c99b5cb@github.com>
 <O8IHlJJQNRrrtcc_N5BSjR2Y30EHaBVfX1ccJUKxlZI=.c0882ed2-ad31-46d6-afd1-e0cba6b218e0@github.com>
 <7dxS3mz2QrOY6SJUIkcyLoGBF_R3_6Y-gPSGgPhZc5M=.b82950ec-f725-4ac0-8531-06787c103b8c@github.com>
Message-ID: <Cs-BROFXqk4gUNOmX-6m65TP0J8niVycHFaq_tXkFZM=.d624c6e3-e959-4a96-af85-7d422b14c6a3@github.com>

On Mon, 29 Sep 2025 15:05:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 218:
>> 
>>> 216: // TODO-FIXME: probes should not fire when caller is _blocked.  assert() accordingly.
>>> 217: 
>>> 218: #define DTRACE_MONITOR_PROBE_COMMON(obj, thread)                           \
>> 
>> I agree that these shouldn't be in objectMonitor.hpp file.  With Legacy locking removed, are these still needed in synchronizer.cpp ?
>
> It would be nice to understand why these are used in general.

These are the DTrace probe points. Whether anyone still uses them ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27538#discussion_r2390119031

From phubner at openjdk.org  Tue Sep 30 07:46:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 30 Sep 2025 07:46:28 GMT
Subject: RFR: 8368885: NMT CommandLine tests can check for error better
In-Reply-To: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
References: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
Message-ID: <FgNhupGwUQMRMmq7IgEiveseoEcCf0-VVS8RLTHLXqI=.bb0e5c3e-e325-49b1-9e94-72a9e5f4af74@github.com>

On Mon, 29 Sep 2025 16:52:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We can check for more specific error text when running the command line tests, the current 'error' string check misses NMT parsing succeeding but NMT initialization failure.
> 
> We also fix the indentation of the test files, let's use 4 spaces in the Java source files.

Thanks!

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/27554#pullrequestreview-3283050071

From fandreuzzi at openjdk.org  Tue Sep 30 07:56:41 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 07:56:41 GMT
Subject: RFR: 8368817: Convert JDK_Version::to_string to use stringStream
 instead of jio_snprintf-chain
In-Reply-To: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com>
References: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com>
Message-ID: <N_WzzCGq5C0nn2UNb3pf8e-aKbQ138iqOtB_aHlPuyw=.6d31bf26-50ae-46e3-a192-920c827f6ad0@github.com>

On Tue, 30 Sep 2025 02:53:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to JDK_Version::to_string to use stringStream to
> accumulate the version string in the buffer, rather than using jio_snprintf to
> write the various pieces.
> 
> Testing: mach5 tier1
> Locally manually examined result of JDK_Version for builds configured with
> different values for various version parameters.

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27567#pullrequestreview-3283086015

From mli at openjdk.org  Tue Sep 30 08:14:43 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 30 Sep 2025 08:14:43 GMT
Subject: RFR: 8367981: Update CompactHashtable for readability [v5]
In-Reply-To: <_ENHK97QTPpGR4z6SezGzyp6vXSJRdSjiQD6nftpmxo=.2a5db5d9-4cc5-4e35-9593-fd5455a10f2f@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
 <YUGwTt3OZfx44FYUhdIVupSE3S_84J_H5_xSjcC-jHY=.d43a87db-4d12-40d5-b884-c892418696bc@github.com>
 <_ENHK97QTPpGR4z6SezGzyp6vXSJRdSjiQD6nftpmxo=.2a5db5d9-4cc5-4e35-9593-fd5455a10f2f@github.com>
Message-ID: <sOHTlTjO5uOxfOCLLx7ak903-heonT-o8aNeNd9G6cM=.81ffab9b-3527-48ff-bdde-0349031943e1@github.com>

On Wed, 24 Sep 2025 22:20:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename 2
>
> LGTM!

@iklam @matias9927 Thank you for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/27360#issuecomment-3350552557

From mli at openjdk.org  Tue Sep 30 08:14:44 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 30 Sep 2025 08:14:44 GMT
Subject: Integrated: 8367981: Update CompactHashtable for readability
In-Reply-To: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
References: <ZiXDZbYvc1e_ygTFyIbdAj1_lV5VdUXc8Sp8U7qOsEc=.794add2f-9c2a-48ae-ab37-99f6a0891d25@github.com>
Message-ID: <8fEOBdf0eSbXpMA7Pw7zwVSjyoxLkTkEsD1QZ3QIyJE=.8382568f-d35c-41c1-8029-ad0a4393bc82@github.com>

On Thu, 18 Sep 2025 10:53:25 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> 
> The comments of CompactHashtable and related classes are out of date, and some comments are unclear, wrong or misleading.
> As the related classes are used in more and more scenarios, it's helpful to update the comments.
> 
> To improve readability (of both the source code and the comments), we should also rename some of the field/parameters to distinguish between the type V (the "value " stored inside the table; it could be a 64-bit pointer) vs "encoded value" (the 32-bit representation of V in the CompactHashtable storage).
> 
> Thanks

This pull request has now been integrated.

Changeset: c0a4c0ba
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0a4c0ba97284d55cfdf857eb5d41fd6189e6c2d
Stats:     83 lines in 2 files changed: 22 ins; 16 del; 45 mod

8367981: Update CompactHashtable for readability

Reviewed-by: iklam, matsaave

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

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

From jsjolen at openjdk.org  Tue Sep 30 08:31:52 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 Sep 2025 08:31:52 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
Message-ID: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>

Hi,

`skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.

We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.

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

Commit messages:
 - Gotta cast
 - Change, add assertion
 - Fix
 - Check whether the next character is in bounds

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

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

From dholmes at openjdk.org  Tue Sep 30 08:31:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Sep 2025 08:31:54 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
Message-ID: <ovRV-7yvaiPV_iNN62eqJ9vBDSKhPkrwXmNFMTuFUpw=.99932309-0edb-4fbe-96a2-35143d5481c9@github.com>

On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
> 
> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.

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

> 4679:     case JVM_SIGNATURE_CLASS: {
> 4680:       if (_major_version < JAVA_1_5_VERSION) {
> 4681:         signature++; length--;

Suggestion:

        signature++;
        length--;

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

> 4684:         // The next character better be a semicolon
> 4685:         if (p != nullptr               && // Parse of field name succeeded.
> 4686:             signature + length > p     && // There is at least one character left to parse.

I find `p - signature < length` a more obvious formulation that there is at least one more character.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2386359217
PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2386359872

From liach at openjdk.org  Tue Sep 30 08:31:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Sep 2025 08:31:55 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
Message-ID: <h456EpVoVkTgFMBtY87ttdsrmJ99iz8_ILNOIrBU1dU=.5403b258-510a-429e-9013-35b8bd35f9df@github.com>

On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
> 
> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.

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

> 4683:         // The next character better be a semicolon
> 4684:         if (p != nullptr               && // Parse succeeded
> 4685:             signature < p              && // p is in range [ signature,

This condition (and the preexisting `(p - signature) > 1`) seems redundant. From what I see, `skip_over_field_name` already rejects empty names, so `signature + 1 < p` should be consistently true. (We should document that return value `> name` in `skip_over_field_name` too

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2382560085

From liach at openjdk.org  Tue Sep 30 08:31:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Sep 2025 08:31:56 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <h456EpVoVkTgFMBtY87ttdsrmJ99iz8_ILNOIrBU1dU=.5403b258-510a-429e-9013-35b8bd35f9df@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
 <h456EpVoVkTgFMBtY87ttdsrmJ99iz8_ILNOIrBU1dU=.5403b258-510a-429e-9013-35b8bd35f9df@github.com>
Message-ID: <a_thVSZSF2KY3omxNkhTg9ASnqQLeqtyxir16Ylwczk=.8c7488a7-80c2-4bdc-9c6a-427264b28b62@github.com>

On Fri, 26 Sep 2025 14:12:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi,
>> 
>> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
>> 
>> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.
>
> src/hotspot/share/classfile/classFileParser.cpp line 4685:
> 
>> 4683:         // The next character better be a semicolon
>> 4684:         if (p != nullptr               && // Parse succeeded
>> 4685:             signature < p              && // p is in range [ signature,
> 
> This condition (and the preexisting `(p - signature) > 1`) seems redundant. From what I see, `skip_over_field_name` already rejects empty names, so `signature + 1 < p` should be consistently true. (We should document that return value `> name` in `skip_over_field_name` too

If we decide to keep this for extra security, `signature < p` is wrong too - it should be `signature + 1 < p` to ensure the resulting class name is not empty, in parity with the old check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2382746649

From jsjolen at openjdk.org  Tue Sep 30 08:31:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 Sep 2025 08:31:56 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <a_thVSZSF2KY3omxNkhTg9ASnqQLeqtyxir16Ylwczk=.8c7488a7-80c2-4bdc-9c6a-427264b28b62@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
 <h456EpVoVkTgFMBtY87ttdsrmJ99iz8_ILNOIrBU1dU=.5403b258-510a-429e-9013-35b8bd35f9df@github.com>
 <a_thVSZSF2KY3omxNkhTg9ASnqQLeqtyxir16Ylwczk=.8c7488a7-80c2-4bdc-9c6a-427264b28b62@github.com>
Message-ID: <x9w0_2zVhyVyKAzoiQHnbDGCJOZPhtpGoGxFCNhIbjY=.480cad3f-eb4a-412b-b28e-1683ef466190@github.com>

On Fri, 26 Sep 2025 15:25:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 4685:
>> 
>>> 4683:         // The next character better be a semicolon
>>> 4684:         if (p != nullptr               && // Parse succeeded
>>> 4685:             signature < p              && // p is in range [ signature,
>> 
>> This condition (and the preexisting `(p - signature) > 1`) seems redundant. From what I see, `skip_over_field_name` already rejects empty names, so `signature + 1 < p` should be consistently true. (We should document that return value `> name` in `skip_over_field_name` too
>
> If we decide to keep this for extra security, `signature < p` is wrong too - it should be `signature + 1 < p` to ensure the resulting class name is not empty, in parity with the old check.

Yeah, let's skip the redundant condition. It's just confusing to read the check. I wonder if that check was meant to mean "is there at least 1 character left to parse?", as to avoid the oob dereference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2383932949

From jsjolen at openjdk.org  Tue Sep 30 08:31:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 Sep 2025 08:31:56 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <ovRV-7yvaiPV_iNN62eqJ9vBDSKhPkrwXmNFMTuFUpw=.99932309-0edb-4fbe-96a2-35143d5481c9@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
 <ovRV-7yvaiPV_iNN62eqJ9vBDSKhPkrwXmNFMTuFUpw=.99932309-0edb-4fbe-96a2-35143d5481c9@github.com>
Message-ID: <3T_3TZxwwmWjwzoSbX3wAhf4vRmwg5hyQ3zZGuV-ENI=.baa3ae6a-a608-4019-82de-24a321cc756b@github.com>

On Sun, 28 Sep 2025 21:47:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi,
>> 
>> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
>> 
>> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.
>
> src/hotspot/share/classfile/classFileParser.cpp line 4686:
> 
>> 4684:         // The next character better be a semicolon
>> 4685:         if (p != nullptr               && // Parse of field name succeeded.
>> 4686:             signature + length > p     && // There is at least one character left to parse.
> 
> I find `p - signature < length` a more obvious formulation that there is at least one more character.

I also added an assertion that at least one character must be parsed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2388731776

From jsjolen at openjdk.org  Tue Sep 30 08:31:58 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 Sep 2025 08:31:58 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
Message-ID: <eHDwYoA2D6gwniPmIqJ-Gj3VooyUKwdyt0fmbljEyp8=.709607cb-ae36-4f94-bf7d-943647afd7d2@github.com>

On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
> 
> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.

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

> 4687:             p[0] == JVM_SIGNATURE_ENDCLASS) {
> 4688:           return p + 1;
> 4689:         }

Should probably do the equivalent length check that is done in other callees.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27528#discussion_r2382375179

From jsjolen at openjdk.org  Tue Sep 30 08:38:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 Sep 2025 08:38:10 GMT
Subject: RFR: 8368817: Convert JDK_Version::to_string to use stringStream
 instead of jio_snprintf-chain
In-Reply-To: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com>
References: <7lxbpEC4RFvAafYp4noztW0mEvomHPeucAmgSNM0nlc=.9911ba17-a7bc-400c-a555-1ac617262e60@github.com>
Message-ID: <P8kCtMUiiwwtkG2i96dX9BEdrRUTh7844xLCNCbMhbk=.2bfb86bb-62de-4a0a-850a-cf5313ec4a56@github.com>

On Tue, 30 Sep 2025 02:53:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to JDK_Version::to_string to use stringStream to
> accumulate the version string in the buffer, rather than using jio_snprintf to
> write the various pieces.
> 
> Testing: mach5 tier1
> Locally manually examined result of JDK_Version for builds configured with
> different values for various version parameters.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27567#pullrequestreview-3283269736

From azafari at openjdk.org  Tue Sep 30 08:39:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 08:39:15 GMT
Subject: RFR: 8368885: NMT CommandLine tests can check for error better
In-Reply-To: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
References: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
Message-ID: <nBsPqBYHLifkjmHRTaEVrIeA7uCbgnxBLwUJ2BYpTyU=.c7919131-d2ee-46f5-8731-22047a404e94@github.com>

On Mon, 29 Sep 2025 16:52:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We can check for more specific error text when running the command line tests, the current 'error' string check misses NMT parsing succeeding but NMT initialization failure.
> 
> We also fix the indentation of the test files, let's use 4 spaces in the Java source files.

Thanks for taking this. LGTM.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27554#pullrequestreview-3283272387

From cnorrbin at openjdk.org  Tue Sep 30 08:45:38 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 30 Sep 2025 08:45:38 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
Message-ID: <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>

> Hi everyone,
> 
> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers.
> 
> For example, consider the call sequence for `os::available_memory()`:
> 
> os::available_memory()
>         |
>         v
> os::Linux::available_memory()
>         |--------------------------------------------
>         v                                           v    
> OSContainer::memory_limit_in_bytes()       or return host physical memory
>         |
>         v
> CgroupSubsystem::memory_limit_in_bytes()
>         |--------------------------------------------
>         v                                           v
> return os::Linux::physical_memory()        or return cgroup v1/v2 limit
> 
> 
> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality:
> * `os::Linux` should focus solely on actual machine memory values.
> * `CgroupSubsystem` should focus exclusively on cgroup memory limits.
> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized.
> 
> 
> A revised structure separates these responsibilities:
> 
> os::available_memory()
>         |--------------------------------------------
>         v                                           v
> OSContainer::memory_limit_in_bytes()       or os::Linux::available_memory()                       
>         |--------------------------------------------
>         v                                           v
> CgroupSubsystem::memory_limit_in_bytes()   os::Linux::physical_memory()
>         |
>         v
> return bounded cgroup v1/v2 limit
> 
> 
> With these changes:
> * `os::Linux` only retrieves machine values.
> * `CgroupSubsystem` works exclusively with cgroup limits.
> * `OSContainer` fetches and passes bounds for the cgroup values.
> * The decision of container or machine value is done in the `os` layer.
> 
> The concrete code changes include:
> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`).
> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also refactored to use the new bool and reference interface introduced in [JDK-8357086](https://bugs.openjdk...

Casper Norrbin 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 branch 'master' into linux-container-mem-restructure
 - keep cgroupsubsystem separate
 - keep os::linux separate

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

Changes: https://git.openjdk.org/jdk/pull/27470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27470&range=01
  Stats: 135 lines in 9 files changed: 32 ins; 27 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/27470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27470/head:pull/27470

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

From cnorrbin at openjdk.org  Tue Sep 30 08:45:39 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 30 Sep 2025 08:45:39 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <eWvz0DaPwzc7l2F6Z-9qsiwUdGD8_PRsg_lyrkTY-Ks=.987e788a-310b-4661-a3c3-4e9f53ce129c@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
 <eWvz0DaPwzc7l2F6Z-9qsiwUdGD8_PRsg_lyrkTY-Ks=.987e788a-310b-4661-a3c3-4e9f53ce129c@github.com>
Message-ID: <MDhdBDh79WCi-ddhhcXEsX8wsxzalfaJWz5-r2Ah5O0=.64876e34-1a78-4499-b0c0-fbc0635a1c74@github.com>

On Thu, 25 Sep 2025 12:03:08 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Looks good to me, but should probably wait until [JDK-8367485](https://github.com/openjdk/jdk/pull/27335) is integrated.

Thank you for reviewing! I've now merged those changes in.

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

PR Comment: https://git.openjdk.org/jdk/pull/27470#issuecomment-3350712427

From azafari at openjdk.org  Tue Sep 30 08:57:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 08:57:09 GMT
Subject: RFR: 8342730: Get rid of SummaryDiff in VMATree [v3]
In-Reply-To: <BhqTL2ei0sMifJXen0l8cLLrf0qta8Oa6LL4-3AgYYc=.ee7e45ce-9813-4a0d-8c31-5cb7992e9d18@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
 <88Ve4wkLTI5s2uzgk3x2Hnf4KZzGC68TP_Et1utmvrM=.62d00c09-98eb-43d3-8b08-d326a9690d47@github.com>
 <BhqTL2ei0sMifJXen0l8cLLrf0qta8Oa6LL4-3AgYYc=.ee7e45ce-9813-4a0d-8c31-5cb7992e9d18@github.com>
Message-ID: <IfXFOin3UBPpjY29sMLls7J-_uFetOouiczbQhiJBhk=.0831d29f-5b2b-4df2-b2eb-00d63694d3fb@github.com>

On Thu, 18 Sep 2025 13:37:34 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari 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 three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _8342730_summary_diff_ref
>>  - better naming for diff
>>  - 8342730: Get rid of SummaryDiff in VMATree
>
> Marked as reviewed by jsjolen (Reviewer).

Thank you @jdksjolen and @Arraying for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26761#issuecomment-3350765374

From azafari at openjdk.org  Tue Sep 30 08:57:11 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 08:57:11 GMT
Subject: Integrated: 8342730: Get rid of SummaryDiff in VMATree
In-Reply-To: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
References: <JShctGmb3UHnG21I3UAOCLu8b9KoGs8u9yO5iw_sUwc=.e0a33104-011f-47b0-bac4-59d18853c4c8@github.com>
Message-ID: <wayTUJvvSapYnHqVKEsfG-Vun1hW4UfK-Iz0qZ_rnqQ=.75011d77-3b20-4ebe-989f-fa5785c273d0@github.com>

On Wed, 13 Aug 2025 13:33:36 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.

This pull request has now been integrated.

Changeset: aea71cca
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aea71ccab7d21ae72564a07f74199eac14c7a958
Stats:     367 lines in 9 files changed: 99 ins; 3 del; 265 mod

8342730: Get rid of SummaryDiff in VMATree

Reviewed-by: jsjolen, phubner

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

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

From azafari at openjdk.org  Tue Sep 30 09:03:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 09:03:15 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v4]
In-Reply-To: <FiDurmvpZZP9Ubnh4kJYcFQvzpGM14JhHCJgMfXwOYw=.3a5c6d7d-c441-4145-bf1f-ffdd57d2f68d@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <9veNrm3XyhTkEtGfzE9lfrra9Rocvo7gVKBVCcvPbuM=.9b80a355-244a-41e7-a354-1b0e91103bc2@github.com>
 <FiDurmvpZZP9Ubnh4kJYcFQvzpGM14JhHCJgMfXwOYw=.3a5c6d7d-c441-4145-bf1f-ffdd57d2f68d@github.com>
Message-ID: <H974vZSt9R0WpAvp5pecH8IA-h-5pW_aeGIa65GTz4o=.b831b77b-27f6-4ecc-92d8-93a78b7e4f56@github.com>

On Mon, 29 Sep 2025 16:31:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari 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 remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - master merge fix
>>  - 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
>
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 265:
> 
>> 263:   inline bool equals(const VirtualMemoryRegion& rgn) const {
>> 264:     return compare(rgn) == 0;
>> 265:   }
> 
> Is this used?

Yes, in `memReporter.cpp:438`, to find if a reserved region is completely committed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390423788

From shade at openjdk.org  Tue Sep 30 09:12:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Sep 2025 09:12:56 GMT
Subject: RFR: 8368885: NMT CommandLine tests can check for error better
In-Reply-To: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
References: <x0BNA73LdMmW6yMKKqA2KYIs5q_3giPOpz0sAMRe6KE=.1a83f326-c59c-4ed8-baa4-bd4d70975575@github.com>
Message-ID: <6lTFwjpbZiyoqgzxhJA3QtYzlg_HtbZ5n6dWwYWIjYY=.230aed45-8ed6-4477-bcd0-468b288bb7d0@github.com>

On Mon, 29 Sep 2025 16:52:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We can check for more specific error text when running the command line tests, the current 'error' string check misses NMT parsing succeeding but NMT initialization failure.
> 
> We also fix the indentation of the test files, let's use 4 spaces in the Java source files.

Makes sense, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27554#pullrequestreview-3283438849

From azafari at openjdk.org  Tue Sep 30 09:41:04 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 09:41:04 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v5]
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <yjwbvp60H6UTSdEHGpGSBtXwoZlV2ET7RggOGxz_kU4=.238a3545-fbf3-4eaf-81cc-3081e0a2cd61@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 incrementally with one additional commit since the last revision:

  fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27137/files
  - new: https://git.openjdk.org/jdk/pull/27137/files/ec846aa4..1f29d6a4

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

  Stats: 17 lines in 1 file changed: 1 ins; 13 del; 3 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 30 09:41:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 09:41:15 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v4]
In-Reply-To: <FiDurmvpZZP9Ubnh4kJYcFQvzpGM14JhHCJgMfXwOYw=.3a5c6d7d-c441-4145-bf1f-ffdd57d2f68d@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <9veNrm3XyhTkEtGfzE9lfrra9Rocvo7gVKBVCcvPbuM=.9b80a355-244a-41e7-a354-1b0e91103bc2@github.com>
 <FiDurmvpZZP9Ubnh4kJYcFQvzpGM14JhHCJgMfXwOYw=.3a5c6d7d-c441-4145-bf1f-ffdd57d2f68d@github.com>
Message-ID: <QCu73QNxFrgLkilTjsajqYQY2pF3tFERAPboNM-jArc=.ec3f3978-6ad3-428d-9c91-3c3c056d82a3@github.com>

On Mon, 29 Sep 2025 16:29:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari 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 remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - master merge fix
>>  - 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
>
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 196:
> 
>> 194:  */
>> 195: class VirtualMemoryRegion {
>> 196:  private:
> 
> Style, pre-existing: Remove this private as it's private by default at the start.

Done

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 200:
> 
>> 198:   size_t          _size;
>> 199:   MemTag          _mem_tag;
>> 200:   NativeCallStack _reserved_stack, _committed_stack;
> 
> Style: Please separate out these into two declarations on two lines.

Done.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 236:
> 
>> 234: 
>> 235:   inline bool contain_address(address addr) const {
>> 236:     assert(is_valid(), "snaity");
> 
> "sanity"

Done.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 244:
> 
>> 242:     assert(sz > 0, "Invalid size");
>> 243:     assert(size() > 0, "Invalid size");
>> 244:     assert(is_valid(), "snaity");
> 
> "sanity"

Done.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 273:
> 
>> 271:   bool is_valid() const { return base() != nullptr && size() != 0;}
>> 272: 
>> 273:   inline void  set_reserved_call_stack(const NativeCallStack& stack) { _reserved_stack = stack; }
> 
> Is this used? Doesn't it make more sense for these values to be constant and the VMR to be an immutable object (in essence).

No it is not used anymore. Removed.
We cannot make VMR immutable, since we need to return a VMR from `tree->find_reseved_region()`. We need it to be COPYABLE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390574174
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390579985
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390573738
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390573312
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2390572942

From azafari at openjdk.org  Tue Sep 30 09:46:03 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 09:46:03 GMT
Subject: RFR: 8365385: [asan] os::pretouch_memory() is not compatible with
 ASAN
In-Reply-To: <TSTrYwxEuyO5p7amac-O3Jn_dPkca__jzPwKqHgo7ng=.d9926853-d0f4-4726-804a-4bf2c7b8feed@github.com>
References: <RlDfFZoCbokM1bM_iHJFYqEul5aH6dEApOKO8wm9Evw=.18f4dfd3-a227-4efe-b36a-6138abfdbee8@github.com>
 <TSTrYwxEuyO5p7amac-O3Jn_dPkca__jzPwKqHgo7ng=.d9926853-d0f4-4726-804a-4bf2c7b8feed@github.com>
Message-ID: <MvO6_9dNOXaQRTS91VbmiBUesdfZtqhqRi0sghmEtYU=.e419815f-a9c4-4405-971f-fa18f1c9657b@github.com>

On Tue, 30 Sep 2025 05:07:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Sorry for the delay, this fell through the cracks somehow. Good. Thanks!

No problem at all. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/27248#issuecomment-3351007366

From sgehwolf at openjdk.org  Tue Sep 30 09:49:11 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Sep 2025 09:49:11 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
 <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
Message-ID: <V0kzueQ7nppf0CYAEtGOBB-NE11F_HQwNmktTX1fF4Q=.d27a1608-3e8d-4500-a21d-95ab61c6509d@github.com>

On Tue, 30 Sep 2025 08:45:38 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers.
>> 
>> For example, consider the call sequence for `os::available_memory()`:
>> 
>> os::available_memory()
>>         |
>>         v
>> os::Linux::available_memory()
>>         |--------------------------------------------
>>         v                                           v    
>> OSContainer::memory_limit_in_bytes()       or return host physical memory
>>         |
>>         v
>> CgroupSubsystem::memory_limit_in_bytes()
>>         |--------------------------------------------
>>         v                                           v
>> return os::Linux::physical_memory()        or return cgroup v1/v2 limit
>> 
>> 
>> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality:
>> * `os::Linux` should focus solely on actual machine memory values.
>> * `CgroupSubsystem` should focus exclusively on cgroup memory limits.
>> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized.
>> 
>> 
>> A revised structure separates these responsibilities:
>> 
>> os::available_memory()
>>         |--------------------------------------------
>>         v                                           v
>> OSContainer::memory_limit_in_bytes()       or os::Linux::available_memory()                       
>>         |--------------------------------------------
>>         v                                           v
>> CgroupSubsystem::memory_limit_in_bytes()   os::Linux::physical_memory()
>>         |
>>         v
>> return bounded cgroup v1/v2 limit
>> 
>> 
>> With these changes:
>> * `os::Linux` only retrieves machine values.
>> * `CgroupSubsystem` works exclusively with cgroup limits.
>> * `OSContainer` fetches and passes bounds for the cgroup values.
>> * The decision of container or machine value is done in the `os` layer.
>> 
>> The concrete code changes include:
>> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`).
>> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also ref...
>
> Casper Norrbin 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 branch 'master' into linux-container-mem-restructure
>  - keep cgroupsubsystem separate
>  - keep os::linux separate

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 674:

> 672:     return memory_limit->value();
> 673:   }
> 674:   jlong mem_limit = contrl->controller()->read_memory_limit_in_bytes(upper_bound);

This removes the logging at the trace level for the upper bound. Intentional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27470#discussion_r2390614627

From cnorrbin at openjdk.org  Tue Sep 30 09:58:55 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 30 Sep 2025 09:58:55 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <V0kzueQ7nppf0CYAEtGOBB-NE11F_HQwNmktTX1fF4Q=.d27a1608-3e8d-4500-a21d-95ab61c6509d@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
 <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
 <V0kzueQ7nppf0CYAEtGOBB-NE11F_HQwNmktTX1fF4Q=.d27a1608-3e8d-4500-a21d-95ab61c6509d@github.com>
Message-ID: <unSAG7tBm9dPsCnWdFgPSsfveA30aVpET8vTqGb0_8I=.1e996244-9015-453b-9c76-217c4d343f60@github.com>

On Tue, 30 Sep 2025 09:46:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Casper Norrbin 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 branch 'master' into linux-container-mem-restructure
>>  - keep cgroupsubsystem separate
>>  - keep os::linux separate
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 674:
> 
>> 672:     return memory_limit->value();
>> 673:   }
>> 674:   jlong mem_limit = contrl->controller()->read_memory_limit_in_bytes(upper_bound);
> 
> This removes the logging at the trace level for the upper bound. Intentional?

Yes, it was intentional. Both cgroup v1/v2 already log the upper bound in `read_memory_limit_in_bytes()` at debug level, along with more information. It felt unnecessary logging the same value twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27470#discussion_r2390652794

From azafari at openjdk.org  Tue Sep 30 10:09:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 30 Sep 2025 10:09:35 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v6]
In-Reply-To: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
Message-ID: <GHakO5HS_bBpXH6DIvfkhMpclt0fbzOjImFFHoJyHYk=.b0ccd55b-ec2f-42ab-8189-b7493f1edd60@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 nine commits:

 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - fixes
 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
 - master merge fix
 - 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=05
  Stats: 187 lines in 12 files changed: 27 ins; 93 del; 67 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 sgehwolf at openjdk.org  Tue Sep 30 10:13:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Sep 2025 10:13:06 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <unSAG7tBm9dPsCnWdFgPSsfveA30aVpET8vTqGb0_8I=.1e996244-9015-453b-9c76-217c4d343f60@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
 <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
 <V0kzueQ7nppf0CYAEtGOBB-NE11F_HQwNmktTX1fF4Q=.d27a1608-3e8d-4500-a21d-95ab61c6509d@github.com>
 <unSAG7tBm9dPsCnWdFgPSsfveA30aVpET8vTqGb0_8I=.1e996244-9015-453b-9c76-217c4d343f60@github.com>
Message-ID: <6JB_JaTomjgnq_9a2P1ytn_uR5oGUnl82A9AWNQZKJA=.a9577a36-5179-445c-9cab-3f517cdd5628@github.com>

On Tue, 30 Sep 2025 09:55:56 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 674:
>> 
>>> 672:     return memory_limit->value();
>>> 673:   }
>>> 674:   jlong mem_limit = contrl->controller()->read_memory_limit_in_bytes(upper_bound);
>> 
>> This removes the logging at the trace level for the upper bound. Intentional?
>
> Yes, it was intentional. Both cgroup v1/v2 already log the upper bound in `read_memory_limit_in_bytes()` at debug level, along with more information. It felt unnecessary logging the same value twice.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27470#discussion_r2390708960

From sgehwolf at openjdk.org  Tue Sep 30 10:13:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Sep 2025 10:13:03 GMT
Subject: RFR: 8292984: Refactor internal container-related interfaces for
 clarity [v2]
In-Reply-To: <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
References: <vJIuSOwLoV06-7IbPF7MEY_RkURMR_bHLOTu9L6Pc4Y=.583f526f-f93d-4b99-8506-4357995cfc35@github.com>
 <p7jrXX25TkrTs9ElTrapSbLBbhCUvlq3MQRI4BsWHQw=.41156cac-2af3-4604-994e-59c2725f27bd@github.com>
Message-ID: <-3WYyZDuF-yIz2Wtxr7NjoBGlQl9R3_UuqdSap1skYY=.a5221469-0698-4cc0-b111-26f2ea60f998@github.com>

On Tue, 30 Sep 2025 08:45:38 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current memory-related code paths in Linux are unclear and convoluted, with responsibilities and data flow crossing between `os::Linux` and various container-related layers.
>> 
>> For example, consider the call sequence for `os::available_memory()`:
>> 
>> os::available_memory()
>>         |
>>         v
>> os::Linux::available_memory()
>>         |--------------------------------------------
>>         v                                           v    
>> OSContainer::memory_limit_in_bytes()       or return host physical memory
>>         |
>>         v
>> CgroupSubsystem::memory_limit_in_bytes()
>>         |--------------------------------------------
>>         v                                           v
>> return os::Linux::physical_memory()        or return cgroup v1/v2 limit
>> 
>> 
>> This structure is difficult to follow. Calls move between `os::Linux` and container subsystems in a confusing manner. Ideally, each component should be responsible only for its relevant functionality:
>> * `os::Linux` should focus solely on actual machine memory values.
>> * `CgroupSubsystem` should focus exclusively on cgroup memory limits.
>> * The selection of which value to use should occur at the `os` layer, based on whether the environment is containerized.
>> 
>> 
>> A revised structure separates these responsibilities:
>> 
>> os::available_memory()
>>         |--------------------------------------------
>>         v                                           v
>> OSContainer::memory_limit_in_bytes()       or os::Linux::available_memory()                       
>>         |--------------------------------------------
>>         v                                           v
>> CgroupSubsystem::memory_limit_in_bytes()   os::Linux::physical_memory()
>>         |
>>         v
>> return bounded cgroup v1/v2 limit
>> 
>> 
>> With these changes:
>> * `os::Linux` only retrieves machine values.
>> * `CgroupSubsystem` works exclusively with cgroup limits.
>> * `OSContainer` fetches and passes bounds for the cgroup values.
>> * The decision of container or machine value is done in the `os` layer.
>> 
>> The concrete code changes include:
>> * Moving container selection logic from `os::Linux::{available/free}_memory()` to `os:{available/free}_memory()`, so `os::Linux` now only deals with machine values (was already the case for `os::physical_memory()`).
>> * Moving `os::Linux::available_memory_in_container()` to `OSContainer` instead, removing container-specific logic from `os::Linux`. Also ref...
>
> Casper Norrbin 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 branch 'master' into linux-container-mem-restructure
>  - keep cgroupsubsystem separate
>  - keep os::linux separate

Looks fine.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27470#pullrequestreview-3283760116

From fandreuzzi at openjdk.org  Tue Sep 30 10:18:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 10:18:48 GMT
Subject: RFR: 8368938: ObjectWaiter::badObjectWaiterPtr could be static
Message-ID: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>

There's apparently no reason against having the symbol shared for all instances. This saves a byte from the definition of `ObjectWaiter`.

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - make static

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

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

From fandreuzzi at openjdk.org  Tue Sep 30 10:44:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 10:44:22 GMT
Subject: Integrated: 8368357: Some source files have initial blank lines
In-Reply-To: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
References: <9121m5P5MFrgd7v8Rl88DaZLT6UBKVUciMcZvWNtqiM=.0fdcc411-6f28-4dc2-bb54-9c37712d22d2@github.com>
Message-ID: <lupnODfjtk9_TV3t95iNjchR-hK4i1Jc57CNPcGDvac=.4ce84f2c-c14c-47c5-b642-5323a9a1b558@github.com>

On Thu, 25 Sep 2025 13:44:13 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Removing some spurious blank lines at the beginning of the file. Looks trivial to me.

This pull request has now been integrated.

Changeset: ba0a6eed
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba0a6eed1a6a22bd4c1d159592b62e054afa401a
Stats:     8 lines in 8 files changed: 0 ins; 8 del; 0 mod

8368357: Some source files have initial blank lines

Reviewed-by: stefank, ayang, serb, jwaters, jpai

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

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

From shade at openjdk.org  Tue Sep 30 10:54:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Sep 2025 10:54:40 GMT
Subject: RFR: 8368938: ObjectWaiter::badObjectWaiterPtr could be static
In-Reply-To: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
References: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
Message-ID: <hqhM9axGRdHMWvXbG-QtqvSQCSutRD7wyFeO4QGMveE=.3662dabe-d589-466f-8a99-384fbbdb2dbf@github.com>

On Tue, 30 Sep 2025 10:11:34 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`.
> 
> Passes tier1 and tier2 (fastdebug).

It does not even have to be a `static` field. It would be cleaner to just use it from our common stash of debugging constants here: https://github.com/openjdk/jdk/blob/ba0a6eed1a6a22bd4c1d159592b62e054afa401a/src/hotspot/share/utilities/globalDefinitions.hpp#L1014-L1032

Maybe add one that discriminates this particular case.

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

PR Review: https://git.openjdk.org/jdk/pull/27571#pullrequestreview-3283986687

From fandreuzzi at openjdk.org  Tue Sep 30 11:33:23 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 11:33:23 GMT
Subject: RFR: 8368938: ObjectWaiter::badObjectWaiterPtr could be static
 [v2]
In-Reply-To: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
References: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
Message-ID: <cbozcaznfHzLmICMBgoyVAZMq6Qun86PEIf3v9_9n2o=.e079ef61-7628-46e1-8796-2d0e47647ab4@github.com>

> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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 three additional commits since the last revision:

 - nn
 - Merge branch 'master' into JDK-8368938
 - make static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27571/files
  - new: https://git.openjdk.org/jdk/pull/27571/files/39b6c46e..7bb52de6

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

  Stats: 1445 lines in 68 files changed: 575 ins; 176 del; 694 mod
  Patch: https://git.openjdk.org/jdk/pull/27571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27571/head:pull/27571

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

From fandreuzzi at openjdk.org  Tue Sep 30 11:33:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 11:33:24 GMT
Subject: RFR: 8368938: ObjectWaiter::badObjectWaiterPtr could be static
 [v2]
In-Reply-To: <hqhM9axGRdHMWvXbG-QtqvSQCSutRD7wyFeO4QGMveE=.3662dabe-d589-466f-8a99-384fbbdb2dbf@github.com>
References: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
 <hqhM9axGRdHMWvXbG-QtqvSQCSutRD7wyFeO4QGMveE=.3662dabe-d589-466f-8a99-384fbbdb2dbf@github.com>
Message-ID: <0omg5Dv8mrDKCtEsjJ6NhjU3GfZ3fGgY6cPHblXtXg8=.340db1e9-bf58-4fa4-9255-ae355359f3ad@github.com>

On Tue, 30 Sep 2025 10:51:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It does not even have to be a static field.

Right, thanks. I changed the references to use `badAddressVal` (7bb52de), let me know if it is appropriate.

Re-running tier1 and tier2.

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

PR Comment: https://git.openjdk.org/jdk/pull/27571#issuecomment-3351547186

From fandreuzzi at openjdk.org  Tue Sep 30 11:38:29 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 30 Sep 2025 11:38:29 GMT
Subject: RFR: 8368938: ObjectWaiter::badObjectWaiterPtr could be static
 [v3]
In-Reply-To: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
References: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
Message-ID: <CPJGOEsZWJ7DB0LMugqznJWIAXOd7aPZ_q5ljA5ggps=.b11557d2-c9f8-451e-9266-6a5a40291034@github.com>

> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27571/files
  - new: https://git.openjdk.org/jdk/pull/27571/files/7bb52de6..b9eb7c4c

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

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

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

From mbaesken at openjdk.org  Tue Sep 30 14:27:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 30 Sep 2025 14:27:22 GMT
Subject: RFR: 8368097: [asan] heap-buffer-overflow reported in
 ClassFileParser::skip_over_field_signature
In-Reply-To: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
References: <coixsdJyUS3ymHjlC_rZg0tiUKsmdw29BsqkXqDtQDc=.0675885a-f932-4bab-9832-49ba7db06099@github.com>
Message-ID: <Zx-Bl6kw8MTK9lCXR1POMkEhEYO-itHWBw31IY6nUoA=.a7121a41-0047-411d-8c72-2987b8cef337@github.com>

On Fri, 26 Sep 2025 12:59:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> `skip_over_field_name` may produce a pointer which is exactly one `char` of bounds, which is the dereferenced by `skip_over_field_signature` when it looks for a semi-colon. This causes an out-of-bounds read, which ASAN caught. The fix is to check whether it's OK to dereference `p` or not.
> 
> We keep the semantics the same other than that, so `skip_over_field_signature` and `skip_over_field_name` can both return a pointer which is one past the valid memory range. Creating such a pointer is explicitly not UB, but dereferencing it is.

Looks good, and I tested your patch with asan enabled and the issue is gone (used the test described in the JBS bug).

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27528#pullrequestreview-3285226641

From shade at openjdk.org  Tue Sep 30 15:23:19 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 Sep 2025 15:23:19 GMT
Subject: RFR: 8368938: Remove ObjectWaiter::badObjectWaiterPtr [v3]
In-Reply-To: <CPJGOEsZWJ7DB0LMugqznJWIAXOd7aPZ_q5ljA5ggps=.b11557d2-c9f8-451e-9266-6a5a40291034@github.com>
References: <IoD5FU3UEZZOBI27ACDkoH_iBU8jk-yDtbUCgL7Br4U=.055c3471-4398-46dc-89e8-47fa70e5f2c3@github.com>
 <CPJGOEsZWJ7DB0LMugqznJWIAXOd7aPZ_q5ljA5ggps=.b11557d2-c9f8-451e-9266-6a5a40291034@github.com>
Message-ID: <4oeODpbnRQ2f-54LQt3U2OYRkP2Ul6088ysaGk-nB_8=.42d89cbd-f612-4d8d-8be5-9c4c178c7b93@github.com>

On Tue, 30 Sep 2025 11:38:29 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> There's apparently no reason against having the symbol shared for all instances. This saves a byte from the memory footprint of `ObjectWaiter`.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include

I am good with switching to `badAddressVal` for this, thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27571#pullrequestreview-3285548634

From pchilanomate at openjdk.org  Tue Sep 30 16:31:37 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 30 Sep 2025 16:31:37 GMT
Subject: RFR: 8360702: runtime/Thread/AsyncExceptionTest.java timed out
Message-ID: <i5g5uManNYDJXGwlG9bwjtdnhngYSOe1nt-1lNcBtqs=.14d2f102-d3e5-49f1-ba85-dd4c4a48d3bb@github.com>

Please review this small test fix. To make sure the worker thread receives the async exception at a safe place, we should avoid using synchronization objects where the worker thread might need to unpark the main thread. Otherwise, if the main thread is virtual, the async exception might be set while the worker is still executing FJP code. See JBS comments for more detail.

I fixed test AsyncExceptionOnMonitorEnter.java too and removed it from test/hotspot/jtreg/ProblemList-Virtual.txt. The alternative was to problem list AsyncExceptionTest.java, but I think it?s better if we can just keep the tests for this mode too.

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/27582/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27582&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360702
  Stats: 48 lines in 3 files changed: 19 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27582/head:pull/27582

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