From shade at openjdk.org  Mon Sep  1 06:28:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Sep 2025 06:28:51 GMT
Subject: RFR: 8345810: Custom launchers must be linked with pthread to
 avoid dynamic linker issues [v2]
In-Reply-To: <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
 <gPLWXCadQzq8dYfEe9AR-dpl8rDTMKYAQmMrwfO6f9o=.8bcd7370-4832-42f9-af42-3f7cf538bbd0@github.com>
Message-ID: <-z8XkGE4okfywDA7MQUq2Or9zZPCSO5EilCgNmtdMJU=.f0c7d5cf-f2cc-4c57-970c-1cd1362c8e88@github.com>

On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more investigation.
>> 
>> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`.
>> 
>> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures
>>  - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures
>>  - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures
>
> Aleksey Shipilev 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:
> 
>  - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it
>  - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror
>  - Change to LIB* variables
>  - Fix

Thanks all! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3241009356

From shade at openjdk.org  Mon Sep  1 06:28:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Sep 2025 06:28:53 GMT
Subject: Integrated: 8345810: Custom launchers must be linked with pthread to
 avoid dynamic linker issues
In-Reply-To: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
References: <pXf8-xw4yhb4gRzNDS4GdcQ8uVF80kA0iLZpqUYKot4=.0cdf9034-43ac-4e66-8349-bfb8157db2fd@github.com>
Message-ID: <avExrm0FgNjOL6wzGB0YdDMWlDPjdnqWrHyYarXUQxw=.d11b4169-b665-496f-b52b-2f2a48648e1b@github.com>

On Thu, 28 Aug 2025 07:43:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more investigation.
> 
> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`.
> 
> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures
>  - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures
>  - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures

This pull request has now been integrated.

Changeset: 685da032
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/685da0323b27abda5ab0484f4c8abaaeeff882ea
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues

Reviewed-by: asemenyuk, erikj, dholmes

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

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

From mbaesken at openjdk.org  Mon Sep  1 06:48:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:48:52 GMT
Subject: RFR: 8362516: Support of GCC static analyzer (-fanalyzer) [v2]
In-Reply-To: <XRjYYckxgdBJpB7wq6jdeN59B-wmk1w_zS20x9L5IHw=.cf9fec41-2f8a-4486-933d-f8ad58900b80@github.com>
References: <GiJa5QHK2Z9eeWDJx2ZM_T57hmc8I_PqTV8VapcGCVU=.4eb80f6c-295f-46fa-9e30-c1d809f67a2f@github.com>
 <XRjYYckxgdBJpB7wq6jdeN59B-wmk1w_zS20x9L5IHw=.cf9fec41-2f8a-4486-933d-f8ad58900b80@github.com>
Message-ID: <r2ojNdcNbvtxssaTKgnbNzOuTN6lMnoiD6uN2Zw1bok=.c19f7d7b-f73d-46b3-97fc-43077a755f6e@github.com>

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

>> Recent versions of GCC have a static code analyzer option (-fanalyzer) that works quite well for C code (but it has still issues with C++).
>> This can be used to identify e.g. some leaks like memory leaks, double close, use of uninitialized data etc. .
>> Some info about it :
>> 
>> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html
>> https://developers.redhat.com/articles/2023/05/31/improvements-static-analysis-gcc-13-compiler
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change description

Hi Erik, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/26989#issuecomment-3241058033

From mbaesken at openjdk.org  Mon Sep  1 06:48:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 1 Sep 2025 06:48:54 GMT
Subject: Integrated: 8362516: Support of GCC static analyzer (-fanalyzer)
In-Reply-To: <GiJa5QHK2Z9eeWDJx2ZM_T57hmc8I_PqTV8VapcGCVU=.4eb80f6c-295f-46fa-9e30-c1d809f67a2f@github.com>
References: <GiJa5QHK2Z9eeWDJx2ZM_T57hmc8I_PqTV8VapcGCVU=.4eb80f6c-295f-46fa-9e30-c1d809f67a2f@github.com>
Message-ID: <Q2yHX_YW6rAWSNdABgrnUdB-byw3Khm61MKWTSDgQr4=.c24d8728-5783-4475-b79d-e5c59b5f3648@github.com>

On Thu, 28 Aug 2025 15:17:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Recent versions of GCC have a static code analyzer option (-fanalyzer) that works quite well for C code (but it has still issues with C++).
> This can be used to identify e.g. some leaks like memory leaks, double close, use of uninitialized data etc. .
> Some info about it :
> 
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html
> https://developers.redhat.com/articles/2023/05/31/improvements-static-analysis-gcc-13-compiler

This pull request has now been integrated.

Changeset: ba90ccc6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba90ccc6a8ca7b0b728568ea614470c85a5f7f8a
Stats:     28 lines in 2 files changed: 28 ins; 0 del; 0 mod

8362516: Support of GCC static analyzer (-fanalyzer)

Reviewed-by: erikj

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

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

From lkorinth at openjdk.org  Mon Sep  1 08:07:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 08:07:48 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth 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 10 additional commits since the last revision:

 - new timeouts
 - Merge branch '_master_jdk' into _8260555
 - update copyright
 - revert added timeout, it is not needed
 - feedback from Mark Sheppard
 - update testing.md, remove makefile link, fix bad text
 - after suggestion from Daniel
 - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
 - After suggestions from Erik and Andrey
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8

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

  Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From lkorinth at openjdk.org  Mon Sep  1 13:21:49 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 13:21:49 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19

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

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

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

From alanb at openjdk.org  Mon Sep  1 13:55:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Sep 2025 13:55:46 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9]
In-Reply-To: <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <TiRHp5dX-u2OuPlu50hedoCquJu_ULL3srzudIySQtM=.f58f3b1f-8b8e-48a0-bde4-058578cbbc13@github.com>
Message-ID: <ujm7_UShZE9eDdqhqg82kiSLMXpbiTi3jzOahQcKKZk=.3c13c859-73ec-4e94-9980-6c49dd414c72@github.com>

On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701

From lkorinth at openjdk.org  Mon Sep  1 16:00:47 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 16:00:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com>

On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:
> 
>> 29:  * @compile SuspendResume2.java
>> 30:  * @run driver jdk.test.lib.FileInstaller . .
>> 31:  * @run main/othervm/native/timeout=700
> 
> Why `700` instead of `480` in this file?

I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387

From lkorinth at openjdk.org  Mon Sep  1 16:09:44 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 1 Sep 2025 16:09:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
 <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>
Message-ID: <XStMsQl326UKR-4OlFju2IInzF6OMuVVMc-mfZ70kh8=.a886c6e5-b103-4b52-aeae-5a8c756c8d89@github.com>

On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).
>
>> while not multiplying a 10x factor with four resulting in a 40x factor.
> 
> Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

Because 40x is a very large timeout factor. I think I might misunderstand you in some way.

My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263

From jvernee at openjdk.org  Mon Sep  1 17:00:41 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 Sep 2025 17:00:41 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build
In-Reply-To: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
Message-ID: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com>

On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
> 
> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
> 
> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
> 
> <details>
> <summary>
> Diff from new to old (backwards):
> </summary>
> 
> 
> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> index 13ef65b..49408a2 100644
> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.Hidden;
>  
> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
> -// Do not edit!
> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>  @AOTSafeClassInitializer
>  final class VarHandleGuards {
>  
> 
> 
> </details>
> 
> Testing: java/lang/invoke.

@PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build?

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

PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3242929547

From lkorinth at openjdk.org  Tue Sep  2 07:29:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 2 Sep 2025 07:29:57 GMT
Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <P6nHDFNjBUkXCKl_HmrKnd59l9Tp4zojuLhIu6HJuMQ=.93c74f49-7b78-4f8e-b7fe-acf499ccc4f1@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

This pull request has now been integrated.

Changeset: 55e7af05
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1
Stats:     901 lines in 342 files changed: 51 ins; 91 del; 759 mod

8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Reviewed-by: alanb, sspitsyn, lmesnik, ihse

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

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

From shade at openjdk.org  Tue Sep  2 12:36:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Sep 2025 12:36:15 GMT
Subject: RFR: 8363966: GHA: Switch cross-compiling sysroots to Debian trixie
Message-ID: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>

Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.

Additional testing:
 - [x] GHA

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

Commit messages:
 - Fix

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

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

From erikj at openjdk.org  Tue Sep  2 12:43:44 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 2 Sep 2025 12:43:44 GMT
Subject: RFR: 8366195: Remove unnecessary quotes around -Ta ml64 assembler
 argument
In-Reply-To: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
References: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
Message-ID: <42hkq6G2gYexw2XfX8sRcIfNxa-0_hj2N1j20eCxUMk=.d028524e-010a-494d-b7b2-27597fe6b023@github.com>

On Sat, 30 Aug 2025 15:34:00 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> This PR cleans up the handling of the -Ta argument by removing the quotes that were unintentionally added around the argument and moving the declaration of the argument to match -Fo as suggested in https://github.com/openjdk/jdk/pull/26791

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27021#pullrequestreview-3176372409

From ayang at openjdk.org  Tue Sep  2 14:51:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 2 Sep 2025 14:51:41 GMT
Subject: RFR: 8363966: GHA: Switch cross-compiling sysroots to Debian
 trixie
In-Reply-To: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
References: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
Message-ID: <xujC1nEmYk2qgnbnwz915MjUIjwiZOioBFLB-mMCo5U=.3d8a2f03-785a-4861-b38f-bf41416ad143@github.com>

On Tue, 2 Sep 2025 12:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.
> 
> Additional testing:
>  - [x] GHA

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27047#pullrequestreview-3176915929

From fyang at openjdk.org  Tue Sep  2 15:18:43 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 2 Sep 2025 15:18:43 GMT
Subject: RFR: 8363966: GHA: Switch cross-compiling sysroots to Debian
 trixie
In-Reply-To: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
References: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
Message-ID: <maPwzPyp4y_4nzSDvCJL3zr5LpJGCIpFvrZuv-qn4LI=.76a00357-0bc4-4530-9ecb-7983d068bef9@github.com>

On Tue, 2 Sep 2025 12:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.
> 
> Additional testing:
>  - [x] GHA

Sounds great! Thanks for doing this!

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27047#pullrequestreview-3177035086

From psandoz at openjdk.org  Tue Sep  2 15:26:45 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 2 Sep 2025 15:26:45 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build
In-Reply-To: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
 <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com>
Message-ID: <E_ZvIA0BJtsXsnNPuvWqkr1ydo_JdfYXM3UvO3OPflc=.1909f563-143e-4483-aed3-e46ac4036765@github.com>

On Mon, 1 Sep 2025 16:57:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build?

At the time there were other priorities and we did not know what the frequency of updates might be, but we left gen code in place just in case (and did use it occasionally). I think this PR is good, addressing tech debt.

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

PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3245808429

From psandoz at openjdk.org  Tue Sep  2 15:32:50 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 2 Sep 2025 15:32:50 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build
In-Reply-To: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
Message-ID: <lQz_Xy8YYlYiubdJYvbXi-HXQGb4uJGX6LyS8G7xLxo=.b326af4f-e5bd-44fe-88e2-46873eae06b1@github.com>

On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
> 
> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
> 
> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
> 
> <details>
> <summary>
> Diff from new to old (backwards):
> </summary>
> 
> 
> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> index 13ef65b..49408a2 100644
> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.Hidden;
>  
> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
> -// Do not edit!
> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>  @AOTSafeClassInitializer
>  final class VarHandleGuards {
>  
> 
> 
> </details>
> 
> Testing: java/lang/invoke.

Looks good. Suggested fixes for a few typos that I think were present in the original documentation.

make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 53:

> 51:  * <p>
> 52:  * The generated class essentially encapsulates pre-compiled LambdaForms,
> 53:  * one for each method, for the most set of common method signatures.

Suggestion:

 * one for each method, for common method signatures.

make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 64:

> 62:  * long, float, double), and 3 shapes then a maximum of 60 methods will be
> 63:  * generated.  However, the number is likely to be less since there
> 64:  * be duplicate signatures.

Suggestion:

 * will be duplicate signatures.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3177077405
PR Review Comment: https://git.openjdk.org/jdk/pull/27009#discussion_r2316436550
PR Review Comment: https://git.openjdk.org/jdk/pull/27009#discussion_r2316438118

From erikj at openjdk.org  Tue Sep  2 16:24:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 2 Sep 2025 16:24:43 GMT
Subject: RFR: 8363966: GHA: Switch cross-compiling sysroots to Debian
 trixie
In-Reply-To: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
References: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
Message-ID: <z87NS8HTCmbt03lFPgmm4KtgV1mGYDz1Ni158Lcagzw=.caece74e-31aa-437f-bd1b-0dd03523422d@github.com>

On Tue, 2 Sep 2025 12:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.
> 
> Additional testing:
>  - [x] GHA

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27047#pullrequestreview-3177310425

From duke at openjdk.org  Tue Sep  2 21:59:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 2 Sep 2025 21:59:41 GMT
Subject: RFR: 8366195: Remove unnecessary quotes around -Ta ml64 assembler
 argument
In-Reply-To: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
References: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
Message-ID: <7zLQA08laiGfE_Va3ufH75olQ_Y6bRfAyDKUaihpUUc=.f878a24d-97ab-4c35-96d0-ec7d95cec647@github.com>

On Sat, 30 Aug 2025 15:34:00 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> This PR cleans up the handling of the -Ta argument by removing the quotes that were unintentionally added around the argument and moving the declaration of the argument to match -Fo as suggested in https://github.com/openjdk/jdk/pull/26791

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27021#issuecomment-3246922452

From liach at openjdk.org  Tue Sep  2 22:20:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Sep 2025 22:20:26 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build [v2]
In-Reply-To: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
Message-ID: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>

> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
> 
> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
> 
> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
> 
> <details>
> <summary>
> Diff from new to old (backwards):
> </summary>
> 
> 
> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> index 13ef65b..49408a2 100644
> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.Hidden;
>  
> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
> -// Do not edit!
> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>  @AOTSafeClassInitializer
>  final class VarHandleGuards {
>  
> 
> 
> </details>
> 
> Testing: java/lang/invoke.

Chen Liang 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:

 - Preexisting typos
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards
 - Restore order
 - 8366455: Move VarHandles.GuardMethodGenerator to execute on build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27009/files
  - new: https://git.openjdk.org/jdk/pull/27009/files/eea34487..2f344afa

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

  Stats: 5872 lines in 591 files changed: 2923 ins; 1274 del; 1675 mod
  Patch: https://git.openjdk.org/jdk/pull/27009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27009/head:pull/27009

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

From duke at openjdk.org  Tue Sep  2 23:07:46 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 2 Sep 2025 23:07:46 GMT
Subject: Integrated: 8366195: Remove unnecessary quotes around -Ta ml64
 assembler argument
In-Reply-To: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
References: <2vbbOER6-xFrr1NnfoS1y1EkAK4aH-c0snbPx7N9vVM=.d2eedccd-7e8b-47f9-b0ba-fea0aca7e049@github.com>
Message-ID: <iwt73agXDiQtuFZoa7yFWJWZWZnI3z6N_e-fB51dRbI=.8f233612-3a60-402d-a3b9-744102466a8f@github.com>

On Sat, 30 Aug 2025 15:34:00 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> This PR cleans up the handling of the -Ta argument by removing the quotes that were unintentionally added around the argument and moving the declaration of the argument to match -Fo as suggested in https://github.com/openjdk/jdk/pull/26791

This pull request has now been integrated.

Changeset: b50c11f9
Author:    Saint Wesonga <saint.wesonga at microsoft.com>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b50c11f9077f071cf5639de7e82ec261e0338532
Stats:     12 lines in 3 files changed: 5 ins; 6 del; 1 mod

8366195: Remove unnecessary quotes around -Ta ml64 assembler argument

Reviewed-by: erikj

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

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

From kbarrett at openjdk.org  Tue Sep  2 23:33:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Sep 2025 23:33:17 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and
 is not always a compile-time constant
Message-ID: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>

Please review this change to offset_of to just use offsetof as it's
implementation. The rationale for this is

(1) Despite being UB for some cases that we use (through C++14), none of the
compilers we use actually treat it as such, other than some compilers issuing
warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)

(2) C++17 changed it to be conditionally defined in those formerly UB cases,
and we'll be switching over to C++17 soon (JDK-8314488).

Until we make the switch to C++17 we need to suppress warnings from some
compilers for such uses. We can remove that warning suppression later.

See the JBS issue for more discussion.

Testing: mach5 tier1

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

Commit messages:
 - offset_of just uses offsetof

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

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

From kbarrett at openjdk.org  Tue Sep  2 23:33:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Sep 2025 23:33:17 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior
 and is not always a compile-time constant
In-Reply-To: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
Message-ID: <qlXjYPzWUdwAjHirj-SWdj11dwmGI0i1VVgyITtqAnA=.52bfa32c-d8ba-4466-b8d1-6eab1e4f6828@github.com>

On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to offset_of to just use offsetof as it's
> implementation. The rationale for this is
> 
> (1) Despite being UB for some cases that we use (through C++14), none of the
> compilers we use actually treat it as such, other than some compilers issuing
> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)
> 
> (2) C++17 changed it to be conditionally defined in those formerly UB cases,
> and we'll be switching over to C++17 soon (JDK-8314488).
> 
> Until we make the switch to C++17 we need to suppress warnings from some
> compilers for such uses. We can remove that warning suppression later.
> 
> See the JBS issue for more discussion.
> 
> Testing: mach5 tier1

Assuming this gets approved, there should be followup issues to (1) remove the unnecessary warning suppression
once we're using C++17, and (2) update uses of offset_of to instead use offsetof directly. I'll file those issues once
this gets approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3247131522

From redestad at openjdk.org  Tue Sep  2 23:44:42 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 2 Sep 2025 23:44:42 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build [v2]
In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
 <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
Message-ID: <mbCQVoGCHNVulFHZ3kXJLO4JmrMZBsXyeGjrnnvAHFk=.c66a5af4-eb6e-4d06-963f-5c8b20d1d9d5@github.com>

On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
>> 
>> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
>> 
>> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
>> 
>> <details>
>> <summary>
>> Diff from new to old (backwards):
>> </summary>
>> 
>> 
>> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> index 13ef65b..49408a2 100644
>> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
>> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>>  import jdk.internal.vm.annotation.ForceInline;
>>  import jdk.internal.vm.annotation.Hidden;
>>  
>> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
>> -// Do not edit!
>> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>>  @AOTSafeClassInitializer
>>  final class VarHandleGuards {
>>  
>> 
>> 
>> </details>
>> 
>> Testing: java/lang/invoke.
>
> Chen Liang 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:
> 
>  - Preexisting typos
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards
>  - Restore order
>  - 8366455: Move VarHandles.GuardMethodGenerator to execute on build

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3178493622

From stefank at openjdk.org  Wed Sep  3 07:31:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Sep 2025 07:31:44 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior
 and is not always a compile-time constant
In-Reply-To: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
Message-ID: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com>

On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to offset_of to just use offsetof as it's
> implementation. The rationale for this is
> 
> (1) Despite being UB for some cases that we use (through C++14), none of the
> compilers we use actually treat it as such, other than some compilers issuing
> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)
> 
> (2) C++17 changed it to be conditionally defined in those formerly UB cases,
> and we'll be switching over to C++17 soon (JDK-8314488).
> 
> Until we make the switch to C++17 we need to suppress warnings from some
> compilers for such uses. We can remove that warning suppression later.
> 
> See the JBS issue for more discussion.
> 
> Testing: mach5 tier1

Nice. Is it worth pushing this so near the transition to compile with C++17 support?

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27061#pullrequestreview-3179298085

From jsjolen at openjdk.org  Wed Sep  3 12:20:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 3 Sep 2025 12:20:41 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior
 and is not always a compile-time constant
In-Reply-To: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
Message-ID: <gre2cCRoxP9fOmngmU4AjJyqxnTAn_wWGbhmrRZvPsk=.bba643d0-51f4-4f70-b0db-d51c03afe4db@github.com>

On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to offset_of to just use offsetof as it's
> implementation. The rationale for this is
> 
> (1) Despite being UB for some cases that we use (through C++14), none of the
> compilers we use actually treat it as such, other than some compilers issuing
> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)
> 
> (2) C++17 changed it to be conditionally defined in those formerly UB cases,
> and we'll be switching over to C++17 soon (JDK-8314488).
> 
> Until we make the switch to C++17 we need to suppress warnings from some
> compilers for such uses. We can remove that warning suppression later.
> 
> See the JBS issue for more discussion.
> 
> Testing: mach5 tier1

Seems good to me. As Stefan hints at, maybe it's worth waiting until C++17 integration and then simplify the PR to only change the macro?

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27061#pullrequestreview-3180362344

From shade at openjdk.org  Wed Sep  3 12:44:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Sep 2025 12:44:47 GMT
Subject: RFR: 8363966: GHA: Switch cross-compiling sysroots to Debian
 trixie
In-Reply-To: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
References: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
Message-ID: <8Je7jsUMmZqUBsc-mhLGaJEekRshL09B-6kVTdnrBxU=.893be0f1-26b1-4aba-9c42-e8f6d5c417fc@github.com>

On Tue, 2 Sep 2025 12:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.
> 
> Additional testing:
>  - [x] GHA

Thanks for reviews! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/27047#issuecomment-3249086557

From shade at openjdk.org  Wed Sep  3 12:44:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Sep 2025 12:44:48 GMT
Subject: Integrated: 8363966: GHA: Switch cross-compiling sysroots to Debian
 trixie
In-Reply-To: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
References: <t3G7H0hietI_mvzG-x5n0YiYK46ZCNsnm_VR31HGVyI=.6f99c327-e9d4-4b7a-a7e1-fabebafb23bd@github.com>
Message-ID: <1CMr2wZVuoBo7fpVl-Z0LeqbHD5TW65k9L4_0H5tZDE=.d4fee86f-48aa-4c88-822e-0e2f596dd570@github.com>

On Tue, 2 Sep 2025 12:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as [JDK-8363965](https://bugs.openjdk.org/browse/JDK-8363965), but switching to Debian trixie. We have waited for about a month for it to stabilize, and it seems good to switch now. The benefit of doing this now is making RISC-V sysroot more stable using the same distro as everything else.
> 
> Additional testing:
>  - [x] GHA

This pull request has now been integrated.

Changeset: 2a5f149b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a5f149bb8e26277778465fff670591c929842de
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8363966: GHA: Switch cross-compiling sysroots to Debian trixie

Reviewed-by: ayang, fyang, erikj

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

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

From syan at openjdk.org  Wed Sep  3 14:41:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 3 Sep 2025 14:41:56 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
Message-ID: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>

Hi all,

Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).

This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.

Testing:
- [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
- [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty


The compilation fails demo as below:


# cat sve.c 
#include <arm_sve.h>
svfloat64_t a() {}
# gcc -march=armv8-a+sve sve.c 
/tmp/ccVOzMzb.s: Assembler messages:
/tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

Commit messages:
 - 8366777: Build fails unknown pseudo-op with old AS on linux-aarch64

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

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

From shade at openjdk.org  Wed Sep  3 14:53:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Sep 2025 14:53:48 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>

On Wed, 3 Sep 2025 14:35:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

We have seen this with [JDK-8343751](https://bugs.openjdk.org/browse/JDK-8343751) as well, and reasoned the GCC+Binutils combination was incompatible: too modern GCC and too old Binutils. In our case, it was the old crosstools-ng generated toolchain. Have you seen this on some standard toolchain?

Anyhow, I believe that failing the build is far better behavior than silently disabling SVE!

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3249591983

From erikj at openjdk.org  Wed Sep  3 16:45:42 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Sep 2025 16:45:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
In-Reply-To: <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>
Message-ID: <h6DLDwy6hozp7JDlTD1ADdpDq8iyFprzrWr_9Rb27b8=.e99d8db2-e12a-4821-b1a0-4414d93d5ec5@github.com>

On Wed, 3 Sep 2025 14:51:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Anyhow, I believe if non-standard toolchain is involved failing the build is far better behavior than silently disabling SVE!

A common pattern for optionally supported features is to add an explicit `--enable/--disable` flag that takes 3 values: yes, no and auto, where the default is auto. There are numerous examples, but one is `--enable-precompiled-headers`. If you don't set it, it will be enabled if supported by the toolchain, otherwise not. If you explicitly enable it, then configure will fail if the toolchain doesn't support it. Perhaps that would be a good fit in this case?

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3249988832

From kbarrett at openjdk.org  Wed Sep  3 18:03:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 3 Sep 2025 18:03:45 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17 [v4]
In-Reply-To: <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
 <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
Message-ID: <M2JRxBkXoGjiToa9X-zdJJhBxlv9nuzw4dGSgZffN2A=.b7494fee-7926-48c1-a2f2-d881bc88a7b0@github.com>

On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to use C++17 for building C++ parts of the JDK. In
>> particular this affects HotSpot. This change also includes an update to the
>> HotSpot Style Guide regarding C++17 features and their use in HotSpot code.
>> 
>> Testing: mach5 tier1-8
>> 
>> This change includes a modification of the Style Guide. Rough consensus among
>> the HotSpot Group members is required to make such a change. Only Group
>> members should vote for approval (via the github PR), though reasoned
>> objections or comments from anyone will be considered. A decision on this
>> proposal will not be made before Friday 5-September-2025 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review process
>> to approve (click on Review Changes > Approve), rather than sending a "vote:
>> yes" email reply that would be normal for a CFV.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing word
>  - stefank suggestions

Any further comments or approvals?

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

PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3250230147

From kbarrett at openjdk.org  Wed Sep  3 18:52:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 3 Sep 2025 18:52:42 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior
 and is not always a compile-time constant
In-Reply-To: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
 <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com>
Message-ID: <EL8ho2jo8mNQPCWqTMVeXhkWCqiK3OT8FkymiuEKx60=.f14f1b87-e6d6-45a5-92af-ee87b38b69e2@github.com>

On Wed, 3 Sep 2025 07:28:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Nice. Is it worth pushing this so near the transition to compile with C++17 support?

Including the warning suppression gives something that's usefully backportable, which would make it
easier to backport changes that happen to include any future `offset_of` to `offsetof` changes.

The warning suppression is harmless in C++17 mode, and can be removed at leisure once that mode is engaged.

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

PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3250377743

From ihse at openjdk.org  Wed Sep  3 18:54:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Sep 2025 18:54:13 GMT
Subject: RFR: 8366836: Don't execute post-IncludeCustomExtension if file was
 not included
Message-ID: <XiYQOeSucnE4snRSprU_AY4iwMTcMSzVpq-BevStICo=.a33b222e-43e2-4324-96dc-138b9c3b359f@github.com>

There is a bug in make/common/MakeIncludeEnd.gmk, which makes it always include the "post" custom extension. In MakeIncludeStart.gmk, the "pre" custom extension is properly guarded by the check if the file has not already been included. This is not the case for the "post" condition, so a custom "post" hook can be included multiple times.

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

Commit messages:
 - 8366836: Don't execute post-IncludeCustomExtension if file was not included

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

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

From kvn at openjdk.org  Wed Sep  3 18:54:47 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Sep 2025 18:54:47 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17 [v4]
In-Reply-To: <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
 <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
Message-ID: <-19Udqn-E9_D82hvJZaOCHz9mc-GK9G_PETnNNqSmxg=.968f5927-87f2-4174-93f3-1c296570ea0d@github.com>

On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to use C++17 for building C++ parts of the JDK. In
>> particular this affects HotSpot. This change also includes an update to the
>> HotSpot Style Guide regarding C++17 features and their use in HotSpot code.
>> 
>> Testing: mach5 tier1-8
>> 
>> This change includes a modification of the Style Guide. Rough consensus among
>> the HotSpot Group members is required to make such a change. Only Group
>> members should vote for approval (via the github PR), though reasoned
>> objections or comments from anyone will be considered. A decision on this
>> proposal will not be made before Friday 5-September-2025 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review process
>> to approve (click on Review Changes > Approve), rather than sending a "vote:
>> yes" email reply that would be normal for a CFV.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing word
>  - stefank suggestions

Approved

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3182008369

From erikj at openjdk.org  Wed Sep  3 20:31:41 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Sep 2025 20:31:41 GMT
Subject: RFR: 8366836: Don't execute post-IncludeCustomExtension if file
 was not included
In-Reply-To: <XiYQOeSucnE4snRSprU_AY4iwMTcMSzVpq-BevStICo=.a33b222e-43e2-4324-96dc-138b9c3b359f@github.com>
References: <XiYQOeSucnE4snRSprU_AY4iwMTcMSzVpq-BevStICo=.a33b222e-43e2-4324-96dc-138b9c3b359f@github.com>
Message-ID: <RIp7mVNslKQdCkUSln_AU1lyx7Vk7C18BSsPVLsSgI4=.bab34748-bf71-4089-8d4d-b7455f529fad@github.com>

On Wed, 3 Sep 2025 18:49:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is a bug in make/common/MakeIncludeEnd.gmk, which makes it always include the "post" custom extension. In MakeIncludeStart.gmk, the "pre" custom extension is properly guarded by the check if the file has not already been included. This is not the case for the "post" condition, so a custom "post" hook can be included multiple times.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27077#pullrequestreview-3182335380

From kbarrett at openjdk.org  Thu Sep  4 04:16:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Sep 2025 04:16:41 GMT
Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior
 and is not always a compile-time constant
In-Reply-To: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
 <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com>
Message-ID: <2-sUpiqfS7H0MswkaAYbTBw9Q3AAx-uVYgVx4-wE2i8=.4b7ac42f-1062-4c57-a1ae-d6418faac87e@github.com>

On Wed, 3 Sep 2025 07:28:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to offset_of to just use offsetof as it's
>> implementation. The rationale for this is
>> 
>> (1) Despite being UB for some cases that we use (through C++14), none of the
>> compilers we use actually treat it as such, other than some compilers issuing
>> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)
>> 
>> (2) C++17 changed it to be conditionally defined in those formerly UB cases,
>> and we'll be switching over to C++17 soon (JDK-8314488).
>> 
>> Until we make the switch to C++17 we need to suppress warnings from some
>> compilers for such uses. We can remove that warning suppression later.
>> 
>> See the JBS issue for more discussion.
>> 
>> Testing: mach5 tier1
>
> Nice. Is it worth pushing this so near the transition to compile with C++17 support?

Thanks for reviews @stefank and @jdksjolen

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

PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3251764296

From kbarrett at openjdk.org  Thu Sep  4 05:44:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 4 Sep 2025 05:44:51 GMT
Subject: Integrated: 8300080: offset_of for GCC/Clang exhibits undefined
 behavior and is not always a compile-time constant
In-Reply-To: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
References: <c1BfcRZh1WB_A_uof9vvOkBbWtiPvH3indA5jHTIVOc=.f93db7e4-46ca-4858-87fe-356908bef605@github.com>
Message-ID: <76UmBZC8eEs0mB-JJcx7A5czIEMe7KJ66xM8UicPmuA=.4f5d7000-2ce8-4bfe-bc06-126fc01dadea@github.com>

On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to offset_of to just use offsetof as it's
> implementation. The rationale for this is
> 
> (1) Despite being UB for some cases that we use (through C++14), none of the
> compilers we use actually treat it as such, other than some compilers issuing
> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?)
> 
> (2) C++17 changed it to be conditionally defined in those formerly UB cases,
> and we'll be switching over to C++17 soon (JDK-8314488).
> 
> Until we make the switch to C++17 we need to suppress warnings from some
> compilers for such uses. We can remove that warning suppression later.
> 
> See the JBS issue for more discussion.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 62bc7b7c
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62bc7b7c4247a62c23ea93cd960c3c0434925c49
Stats:     26 lines in 4 files changed: 5 ins; 20 del; 1 mod

8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant

Reviewed-by: stefank, jsjolen

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

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

From iwalulya at openjdk.org  Thu Sep  4 06:08:44 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 4 Sep 2025 06:08:44 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17 [v4]
In-Reply-To: <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
 <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
Message-ID: <qPpMkuZ-9bkQKTYulr9-1b_dfrT6ARt-x88qVTpxfMY=.64717be1-e11a-4da3-bff4-5639d3ee0e63@github.com>

On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to use C++17 for building C++ parts of the JDK. In
>> particular this affects HotSpot. This change also includes an update to the
>> HotSpot Style Guide regarding C++17 features and their use in HotSpot code.
>> 
>> Testing: mach5 tier1-8
>> 
>> This change includes a modification of the Style Guide. Rough consensus among
>> the HotSpot Group members is required to make such a change. Only Group
>> members should vote for approval (via the github PR), though reasoned
>> objections or comments from anyone will be considered. A decision on this
>> proposal will not be made before Friday 5-September-2025 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review process
>> to approve (click on Review Changes > Approve), rather than sending a "vote:
>> yes" email reply that would be normal for a CFV.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing word
>  - stefank suggestions

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3183573272

From syan at openjdk.org  Thu Sep  4 06:57:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 06:57:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
In-Reply-To: <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>
Message-ID: <r_0UYA3QBbmPsTJpXZVdO2X8keZl2cueGrz0DIm5Xrw=.34c3ce0e-91ec-41c1-ab50-86f479e9ba8b@github.com>

On Wed, 3 Sep 2025 14:51:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In our case, it was the old crosstools-ng generated toolchain. Have you seen this on some standard toolchain?

I observed this failure on ubuntu18 with gcc10 and the system-native bintuils toolchain. The gcc10 was installed from ppa:ubuntu-toolchain-r soure by apt install. Gcc10 and binutils are all native: jdk build on linux-aarch64 mahchine, the build target is linux-aarch64 . We choose this combination because this will make jdk build depencies lower glibc version.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3252181354

From syan at openjdk.org  Thu Sep  4 06:57:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 06:57:43 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
In-Reply-To: <h6DLDwy6hozp7JDlTD1ADdpDq8iyFprzrWr_9Rb27b8=.e99d8db2-e12a-4821-b1a0-4414d93d5ec5@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <GRWfcyr1mDR_N39G6MlhJ_9FfKCXOXSjUTd5mKOvll4=.5bd88771-bee7-4221-81ae-1514c56850ac@github.com>
 <h6DLDwy6hozp7JDlTD1ADdpDq8iyFprzrWr_9Rb27b8=.e99d8db2-e12a-4821-b1a0-4414d93d5ec5@github.com>
Message-ID: <fle34AlQOOTCEJgeY8s5LXpAQZP61mupO_q9C8upvTQ=.a0a76dd9-3e52-41a8-ba9c-210bd5ec01d1@github.com>

On Wed, 3 Sep 2025 16:42:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> A common pattern for optionally supported features is to add an explicit --enable/--disable flag that takes 3 values: yes, no and auto, where the default is auto.

Thanks for the advices. I think this will be a good choice. I will try this later.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3252185602

From ihse at openjdk.org  Thu Sep  4 13:20:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Sep 2025 13:20:56 GMT
Subject: Integrated: 8366836: Don't execute post-IncludeCustomExtension if file
 was not included
In-Reply-To: <XiYQOeSucnE4snRSprU_AY4iwMTcMSzVpq-BevStICo=.a33b222e-43e2-4324-96dc-138b9c3b359f@github.com>
References: <XiYQOeSucnE4snRSprU_AY4iwMTcMSzVpq-BevStICo=.a33b222e-43e2-4324-96dc-138b9c3b359f@github.com>
Message-ID: <vUeIRz1_JT0RW67NWD9lnpZTW6xgI9dyDW7bpyGFOGU=.7741f8e8-8ca5-4cff-8e2d-fceffd0c0c87@github.com>

On Wed, 3 Sep 2025 18:49:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is a bug in make/common/MakeIncludeEnd.gmk, which makes it always include the "post" custom extension. In MakeIncludeStart.gmk, the "pre" custom extension is properly guarded by the check if the file has not already been included. This is not the case for the "post" condition, so a custom "post" hook can be included multiple times.

This pull request has now been integrated.

Changeset: 80873a09
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80873a09bf8392d98d20273e0688b17c62252242
Stats:     10 lines in 2 files changed: 5 ins; 1 del; 4 mod

8366836: Don't execute post-IncludeCustomExtension if file was not included

Reviewed-by: erikj

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

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

From syan at openjdk.org  Thu Sep  4 13:40:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 13:40:21 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v2]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <EjiQFNGlC_T32HgkhEchoLrYpjFVtYWig2eI6ZE7V6w=.33b4508a-0799-4cb3-9765-0b238d923f6b@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Add configure option --enable-aarch64-sve to enable or disable sve explicitly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/50048bf9..3791f269

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

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

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

From syan at openjdk.org  Thu Sep  4 13:42:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 13:42:59 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v3]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <vKCs9mlxEHBLrqNRJoCJ-ZJNcIdkdtOK_H_kZkVHr2s=.903fcd72-0d27-4e09-944f-c7b88376a29e@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Remove prefix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/3791f269..e8823a92

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

  Stats: 54 lines in 1 file changed: 11 ins; 14 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/27073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27073/head:pull/27073

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

From syan at openjdk.org  Thu Sep  4 13:45:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 13:45:57 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v4]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Add the original comments for -ftrivial-auto-var-init=zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/e8823a92..5b049ec9

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

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

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

From syan at openjdk.org  Thu Sep  4 13:57:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 4 Sep 2025 13:57:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v4]
In-Reply-To: <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>
Message-ID: <ow-vi2hCRPSPyjQ4sQcB1j-wPFgW1nyjfipVsG0VSTw=.adb49552-2663-446d-a50a-764ccf306c40@github.com>

On Thu, 4 Sep 2025 13:45:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the original comments for -ftrivial-auto-var-init=zero

I have updated this PR which add configure parameter --enable-aarch64-sve to enable '-march=armv8-a+sve' forcely.

Testing:

1. On linux-aarch64 gcc12.3.1 as2.37

- [x] On linux-aarch64 gcc12.3.1 as2.37, and run 'bash configure --enable-aarch64-sve', config.log shows SVE_CFLAGS='-march=armv8-a+sve'
- [x] On linux-aarch64 gcc12.3.1 as2.37, and run 'bash configure --disable-aarch64-sve', config.log shows SVE_CFLAGS=''
- [x] On linux-aarch64 gcc12.3.1 as2.37, and run 'bash configure', config.log shows SVE_CFLAGS='-march=armv8-a+sve'


2. On linux-aarch64 gcc10.3.0 as2.30
- [x] On linux-aarch64 gcc10.3.0 as2.30, and run 'bash configure --enable-aarch64-sve', configure report error "--enable-aarch64-sve=yes but compiler does not support SVE"
- [x]  On linux-aarch64 gcc10.3.0 as2.30, and run 'bash configure --enable-aarch64-sve', configure report error "--enable-aarch64-sve=yes but compiler does not support SVE", config.log shows SVE_CFLAGS=''

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3253851324

From ihse at openjdk.org  Thu Sep  4 15:34:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Sep 2025 15:34:00 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell
Message-ID: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>

When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.

This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

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

Commit messages:
 - 8233115: Protect ExecuteWithLog from running with redirection without a subshell

Changes: https://git.openjdk.org/jdk/pull/27096/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233115
  Stats: 32 lines in 5 files changed: 7 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27096/head:pull/27096

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

From ihse at openjdk.org  Thu Sep  4 15:34:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Sep 2025 15:34:00 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell
In-Reply-To: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
Message-ID: <bFsD4CMoWHHWgwUEyG_gl3A41-gnT6cL87jrQCkIzQE=.f21bacda-8a5f-46f2-aedc-a1ecde4c68df@github.com>

On Thu, 4 Sep 2025 14:03:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
> 
> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

I've tested our internal "builds" CI suite tier1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/27096#issuecomment-3254251386

From erikj at openjdk.org  Thu Sep  4 16:53:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Sep 2025 16:53:45 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v4]
In-Reply-To: <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>
Message-ID: <6lxkhTQJ8KxL1QMikZYqP8DAZQDEwsRIVoTCQH2Ay2g=.18440adc-463d-40f5-b729-02eb9ac6419b@github.com>

On Thu, 4 Sep 2025 13:45:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the original comments for -ftrivial-auto-var-init=zero

Please convert this to using `UTIL_ARG_ENABLE` instead of `AC_ARG_ENABLE`. There should be several examples available. Using this macro will make the code easier to understand and promotes unified behavior for all corner cases.

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

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3186206029

From erikj at openjdk.org  Thu Sep  4 16:56:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Sep 2025 16:56:48 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell
In-Reply-To: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
Message-ID: <xwt03eOrHtWq6r8FERPWs-eEScfIj_U-HICpZ_0-qDE=.8c0c3d16-f118-4ac8-80c7-a382a7122ed6@github.com>

On Thu, 4 Sep 2025 14:03:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
> 
> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

make/common/MakeBase.gmk line 306:

> 304:   $(call MakeDir, $(dir $(strip $1)) $(MAKESUPPORT_OUTPUTDIR)/failure-logs) \
> 305:   $(call WriteFile, $2, $(strip $1).cmdline) \
> 306:   ( $(RM) $(strip $1).log && $(if $(call is_redirect, $2),$(LEFT_PAREN) )$(strip $2)$(if $(call is_redirect, $2), $(RIGHT_PAREN)) > >($(TEE) -a $(strip $1).log) 2> >($(TEE) -a $(strip $1).log >&2) || \

Consider breaking these lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27096#discussion_r2322796527

From cstein at openjdk.org  Thu Sep  4 22:01:57 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 4 Sep 2025 22:01:57 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v4]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8
 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
 - Update to use correct library directories
   
   See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/56006240..12b0d0f5

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

  Stats: 20940 lines in 1016 files changed: 14715 ins; 2669 del; 3556 mod
  Patch: https://git.openjdk.org/jdk/pull/26261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261

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

From syan at openjdk.org  Fri Sep  5 01:55:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 5 Sep 2025 01:55:20 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v5]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <ZHE5lDaqSXULzZWUbOPucnpeOXQ0D5yG7rlsZfptoFg=.633c74d2-ea11-4bf0-8243-0c5c5668c2c0@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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 five additional commits since the last revision:

 - Merge branch 'master' of github.com:openjdk/jdk into jbs8366777
 - Add the original comments for -ftrivial-auto-var-init=zero
 - Remove prefix whitespace
 - Add configure option --enable-aarch64-sve to enable or disable sve explicitly
 - 8366777: Build fails unknown pseudo-op with old AS on linux-aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/5b049ec9..1e477b84

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

  Stats: 3553 lines in 230 files changed: 2299 ins; 273 del; 981 mod
  Patch: https://git.openjdk.org/jdk/pull/27073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27073/head:pull/27073

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

From syan at openjdk.org  Fri Sep  5 06:16:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 5 Sep 2025 06:16:01 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/1e477b84..21c7576b

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

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

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

From syan at openjdk.org  Fri Sep  5 06:52:10 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 5 Sep 2025 06:52:10 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v4]
In-Reply-To: <6lxkhTQJ8KxL1QMikZYqP8DAZQDEwsRIVoTCQH2Ay2g=.18440adc-463d-40f5-b729-02eb9ac6419b@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <AA4Gzee0qzSXt3xw2nCGVpHyYD4RfSVxlDgh1TG6BYI=.25f8c328-49b6-47f0-a9e1-9866749dd919@github.com>
 <6lxkhTQJ8KxL1QMikZYqP8DAZQDEwsRIVoTCQH2Ay2g=.18440adc-463d-40f5-b729-02eb9ac6419b@github.com>
Message-ID: <__v9_bBr9w2_7rDOOwkrWJJGteW-LCpf-Y49NirNkqc=.446d5d17-77aa-4c03-87a0-396c7bc4b1a0@github.com>

On Thu, 4 Sep 2025 16:51:18 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Please convert this to using `UTIL_ARG_ENABLE` instead of `AC_ARG_ENABLE`. There should be several examples available. Using this macro will make the code easier to understand and promotes unified behavior for all corner cases.

I have updated PR as use `UTIL_ARG_ENABLE` instead of `AC_ARG_ENABLE`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3257263566

From ihse at openjdk.org  Fri Sep  5 08:48:47 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 08:48:47 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell [v2]
In-Reply-To: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
Message-ID: <Bron3k6JtQOmoVQSruc2IbkyWvVwZaQf2ImT4yCygSs=.aa3b30ff-76cd-4674-b8dd-3e3e8a111592@github.com>

> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
> 
> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

Magnus Ihse Bursie 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 safe-execute-with-redirect
 - 8233115: Protect ExecuteWithLog from running with redirection without a subshell

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27096/files
  - new: https://git.openjdk.org/jdk/pull/27096/files/836558ab..c5111837

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

  Stats: 4126 lines in 245 files changed: 2630 ins; 395 del; 1101 mod
  Patch: https://git.openjdk.org/jdk/pull/27096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27096/head:pull/27096

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

From ihse at openjdk.org  Fri Sep  5 08:55:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 08:55:26 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell [v3]
In-Reply-To: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
Message-ID: <ksZA3YwQquUuOCBY75BpMcEccKO2yDq4atlYdJHKbeM=.7601bf2c-2895-49c7-bbdb-ba67848dda89@github.com>

> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
> 
> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Break all lines to fit in 80 chars
 - Break long lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27096/files
  - new: https://git.openjdk.org/jdk/pull/27096/files/c5111837..768eec07

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

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

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

From ihse at openjdk.org  Fri Sep  5 08:55:27 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 08:55:27 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell [v3]
In-Reply-To: <xwt03eOrHtWq6r8FERPWs-eEScfIj_U-HICpZ_0-qDE=.8c0c3d16-f118-4ac8-80c7-a382a7122ed6@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
 <xwt03eOrHtWq6r8FERPWs-eEScfIj_U-HICpZ_0-qDE=.8c0c3d16-f118-4ac8-80c7-a382a7122ed6@github.com>
Message-ID: <S0gykX49J_xfs0xSeuCAg8hy6oAutcJiDyy9kqmqScc=.42caa1ee-9ceb-421d-8e2e-726ed3371bcd@github.com>

On Thu, 4 Sep 2025 16:54:27 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Break all lines to fit in 80 chars
>>  - Break long lines
>
> make/common/MakeBase.gmk line 306:
> 
>> 304:   $(call MakeDir, $(dir $(strip $1)) $(MAKESUPPORT_OUTPUTDIR)/failure-logs) \
>> 305:   $(call WriteFile, $2, $(strip $1).cmdline) \
>> 306:   ( $(RM) $(strip $1).log && $(if $(call is_redirect, $2),$(LEFT_PAREN) )$(strip $2)$(if $(call is_redirect, $2), $(RIGHT_PAREN)) > >($(TEE) -a $(strip $1).log) 2> >($(TEE) -a $(strip $1).log >&2) || \
> 
> Consider breaking these lines.

Good point. I turned all of them into 80 char max. It's both helpful and hurtful for readability, but let's stick to our standard.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27096#discussion_r2324505388

From syan at openjdk.org  Fri Sep  5 08:59:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 5 Sep 2025 08:59:11 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
Message-ID: <ErFokKoi4DeNXsnDjDxE_u-QPUtSmi4HrzI-cvq942s=.af3c9479-fd5c-472f-b5ce-c7cc98eb7a56@github.com>

On Fri, 5 Sep 2025 06:16:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE

GHA report test TestAliasingFuzzer.java#vanilla fails on windows-x64, the fails maybe same to https://bugs.openjdk.org/browse/JDK-8366940. I think it's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3257601741

From matthias.baesken at sap.com  Fri Sep  5 11:43:31 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 5 Sep 2025 11:43:31 +0000
Subject: Mixture of product and fastdebug builds in GHA
Message-ID: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi, we recently had a PR that failed our fastdebug builds, but worked nicely with product.
Of course this can happen;  but I was surprised to see that the  GHAs of this PR were all 'green' .

So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ?
If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug  ?

At least on Linux, AIX and Windows the build times of our nightly product and fastdebug makes are not so much different, so regarding resource consumption/build times
this might be fine on some platforms.

Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250905/bb82bffd/attachment-0001.htm>

From erikj at openjdk.org  Fri Sep  5 12:42:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 12:42:10 GMT
Subject: RFR: 8233115: Protect ExecuteWithLog from running with redirection
 without a subshell [v3]
In-Reply-To: <ksZA3YwQquUuOCBY75BpMcEccKO2yDq4atlYdJHKbeM=.7601bf2c-2895-49c7-bbdb-ba67848dda89@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
 <ksZA3YwQquUuOCBY75BpMcEccKO2yDq4atlYdJHKbeM=.7601bf2c-2895-49c7-bbdb-ba67848dda89@github.com>
Message-ID: <abwm-vVQT0AohbSpREpmCLczebEd4rfJLAVuIY24rqo=.d75a1fa1-456b-4e8f-9f49-0eb22f024332@github.com>

On Fri, 5 Sep 2025 08:55:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
>> 
>> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Break all lines to fit in 80 chars
>  - Break long lines

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27096#pullrequestreview-3189211393

From erikj at openjdk.org  Fri Sep  5 13:04:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 13:04:14 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
Message-ID: <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>

On Fri, 5 Sep 2025 06:16:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE

make/autoconf/flags-cflags.m4 line 950:

> 948:       # check the compiler and binutils support sve or not
> 949:       AC_MSG_CHECKING([if Arm SVE ACLE is supported])
> 950:       AC_COMPILE_IFELSE([AC_LANG_PROGRAM(

Now that I started looking closer at this, I realize that we are inside a macro that gets called for both the BUILD and TARGET compiler (note the $2 prefix on several variables). For a call to `AC_COMPILER_IFELSE` to work correctly in that context, you need to temporarily change `CC` and `CFLAGS` to the correct compiler and flags setup. See the definition of `FLAGS_C_COMPILER_CHECK_ARGUMENTS` in flags.m4 to see how that is done.

make/autoconf/flags-cflags.m4 line 981:

> 979:       if test "x$$2SVE_CFLAGS" != "x" && test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
> 980:         INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
> 981:         FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],

When calling `FLAGS_COMPILER_CHECK_ARGUMENTS` you from this context, you need to include the `PREFIX` argument. See examples further up in this file.

make/autoconf/flags-cflags.m4 line 996:

> 994: AC_DEFUN([BPERF_SETUP_SVE],
> 995: [
> 996:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,

The idea with this macro is that you put the supported check and actions on enabled/disabled in the call and let it handle the logic. It shouldn't be moved to a separate macro. Also, macros defined in this file should have the `FLAGS` prefix, not `BPERF`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2325028873
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2325031564
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2325022758

From ihse at openjdk.org  Fri Sep  5 13:34:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 13:34:20 GMT
Subject: Integrated: 8233115: Protect ExecuteWithLog from running with
 redirection without a subshell
In-Reply-To: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
References: <sXXAFS7lAp45zBJc4D6JCbxVVK7bLaLeiXCJnOibpcY=.c752f238-aaaa-47d8-9104-5e9a8fb56731@github.com>
Message-ID: <VuDkqV7S7c6cwAVcsSWosgwWZdSDKiY3DZMSyFJ1Zc8=.74f7faa4-566d-4b03-8ad3-2db252a821ba@github.com>

On Thu, 4 Sep 2025 14:03:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When calling ExecuteWithLog with a redirection (using > or, possibly, <), the entire command needs to be executed in a subshell, that is, inside a pair of parentheses. This is the callers obligation to ensure, but we have proven multiple times that this is hard to keep in mind, and we got several cases of race conditions due to missing this.
> 
> This PR changes the implementation of ExecuteWithLog so it checks if the command line contains redirection, and automatically add the subshell parentheses in that case. The alternative would have been to always execute in a subshell, but that would have been very expensive on Windows.

This pull request has now been integrated.

Changeset: 124fcf1d
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/124fcf1d9abb6cafe34637ba357617c7c7be56c8
Stats:     41 lines in 5 files changed: 14 ins; 5 del; 22 mod

8233115: Protect ExecuteWithLog from running with redirection without a subshell

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Fri Sep  5 15:42:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 15:42:26 GMT
Subject: RFR: 8332872: SetupExecute should cd to temp directory
Message-ID: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>

Some commands create junk files all around in the current directory. We should change directory to a special working dir (typically the support dir) in SetupExecute, before running any command.

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

Commit messages:
 - Merge branch 'master' into execute-in-work-dir
 - Jmod workaround did not help; try this instead
 - Remove debug code
 - Separate support dir for each jmod
 - 8332872: SetupExecute should cd to temp directory

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

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

From ihse at openjdk.org  Fri Sep  5 15:42:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 15:42:26 GMT
Subject: RFR: 8332872: SetupExecute should cd to temp directory
In-Reply-To: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
References: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
Message-ID: <45Zpt7yyGwljWvOGwlje_uIQYIoNtzo3bWl-dcMZ1Bo=.4e675e8e-5bf0-43a1-8e7f-1191e9598546@github.com>

On Thu, 4 Sep 2025 15:34:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some commands create junk files all around in the current directory. We should change directory to a special working dir (typically the support dir) in SetupExecute, before running any command.

Honestly, the Windows build failures baffles me:

* For target support_images_jmods__create_java.datatransfer.jmod_exec:
Error: file already exists: _create_java.compiler.jmod_pre.marker
* For target support_images_jmods__create_java.desktop.jmod_exec:
Error: file already exists: _create_java.compiler.jmod_pre.marker
* For target support_images_jmods__create_java.instrument.jmod_exec:
Error: file already exists: _create_java.compiler.jmod_pre.marker
* For target support_images_jmods__create_java.logging.jmod_exec:
Error: file already exists: _create_java.compiler.jmod_pre.marker


I could reproduce it locally, but that did not make it better. Just trying to build any individual jmod (e.g. `make java.instrument-jmod`) ended up in the `Error: file already exists: _create_<SOME OTHER MOD>.jmod_pre.marker`, where `<SOME OTHER MOD>` is the name of another mod that had been previously processed. This is not passed into CreateJmod.gmk; it seems make, or something we call from make, looks through the directory and finds existing files. I could not for my life understand why or how, not even exactly what was generating the "file already exists" error, nor what was provoking it. After spending too much time on it, I concluded it is likely a make for Windows bug, and decided to work around it instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/27103#issuecomment-3258122013

From ihse at openjdk.org  Fri Sep  5 15:43:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 15:43:32 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <3R3SyNx6jYRhyK-xJwmoscTX2oSAV0zzQWHW2AYDf-A=.6bff4b0c-2e79-4648-a7d9-a42a559c4b48@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

I have verified that the generated java source code in gensrc is byte-by-byte identical with and without this patch. That is really all that is needed in terms of correctness, but to make sure I do not run into some unexpected problem I am also running a confirmation round on our internal CI.

Hm, something is messing up the command lines on the GHA hosts. Funny, I did not see it when testing elsewhere. I'll look into it.

For the record: the changes in the X-Coder template means that additional empty lines will be inserted in the generated source. This has no real effect on anything substantial, but it means that line numbers change, which make a complete byte-by-byte comparison fail for anything that is dependent on these classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250651080
PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250722749
PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3258508787

From ihse at openjdk.org  Fri Sep  5 15:43:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 15:43:32 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
Message-ID: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>

Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

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

Commit messages:
 - Fix syntax error
 - Don't use $(if ...) for KEYS.
 - Move weird characters in template expansion from command line to the template itself
 - Merge branch 'master' into cleanup-spp-gensrc
 - 8366837: Clean up gensrc by spp.Spp

Changes: https://git.openjdk.org/jdk/pull/27078/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366837
  Stats: 1321 lines in 9 files changed: 523 ins; 562 del; 236 mod
  Patch: https://git.openjdk.org/jdk/pull/27078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27078/head:pull/27078

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

From liach at openjdk.org  Fri Sep  5 16:03:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 16:03:12 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build
In-Reply-To: <E_ZvIA0BJtsXsnNPuvWqkr1ydo_JdfYXM3UvO3OPflc=.1909f563-143e-4483-aed3-e46ac4036765@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
 <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com>
 <E_ZvIA0BJtsXsnNPuvWqkr1ydo_JdfYXM3UvO3OPflc=.1909f563-143e-4483-aed3-e46ac4036765@github.com>
Message-ID: <wg861m5ZM3tklzCIN8g0bDYMTIKl5k53gjLzA8QQLhU=.4fe5b772-ceba-4325-bace-86aec42fe769@github.com>

On Tue, 2 Sep 2025 15:24:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build?
>
>> @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build?
> 
> At the time there were other priorities and we did not know what the frequency of updates might be, but we left gen code in place just in case (and did use it occasionally). I think this PR is good, addressing tech debt.

Can @PaulSandoz or @JornVernee re-review this patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3258882442

From psandoz at openjdk.org  Fri Sep  5 16:46:12 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 5 Sep 2025 16:46:12 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build [v2]
In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
 <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
Message-ID: <Z_boYfbKNT-LffGILJb_aMrMQmXw8N357ODsGhUhQCI=.6e0d0f14-3235-4d10-a989-ddffb05fe62d@github.com>

On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
>> 
>> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
>> 
>> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
>> 
>> <details>
>> <summary>
>> Diff from new to old (backwards):
>> </summary>
>> 
>> 
>> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> index 13ef65b..49408a2 100644
>> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
>> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>>  import jdk.internal.vm.annotation.ForceInline;
>>  import jdk.internal.vm.annotation.Hidden;
>>  
>> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
>> -// Do not edit!
>> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>>  @AOTSafeClassInitializer
>>  final class VarHandleGuards {
>>  
>> 
>> 
>> </details>
>> 
>> Testing: java/lang/invoke.
>
> Chen Liang 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:
> 
>  - Preexisting typos
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards
>  - Restore order
>  - 8366455: Move VarHandles.GuardMethodGenerator to execute on build

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3190082576

From ihse at openjdk.org  Fri Sep  5 17:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 17:18:15 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <3GbZE6bnaw9k543kmYqbPXW-sTX_6-ToUsorSTpEJ-0=.b6fb443e-9a13-4478-830f-633ec21dfb47@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

This has passed Oracle internal CI testing for "builds-infra" tier 1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3259183136

From ihse at openjdk.org  Fri Sep  5 17:19:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 17:19:10 GMT
Subject: RFR: 8332872: SetupExecute should cd to temp directory
In-Reply-To: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
References: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
Message-ID: <zfy0bei8c2Gy9wQStxClsXaKdmN3cxq-qjFOddWw3qo=.f91affe2-871b-4f0a-ae68-629f9274f0e2@github.com>

On Thu, 4 Sep 2025 15:34:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some commands create junk files all around in the current directory. We should change directory to a special working dir (typically the support dir) in SetupExecute, before running any command.

This has passed Oracle internal CI testing for "builds-infra" tier 1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/27103#issuecomment-3259185408

From kbarrett at openjdk.org  Fri Sep  5 20:50:23 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 5 Sep 2025 20:50:23 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17 [v4]
In-Reply-To: <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
 <rEQkhn8Eg5St0-tOkwIs7xmpeYapp7LgHAnpeuapv4A=.a053fd4d-40e7-4dbf-9947-7af0aec6333d@github.com>
Message-ID: <xBKKewe0CjYjNyC37MkylWwT9aQ4GhXgA4CMPdNulwk=.c6c9df93-49c6-4919-aca2-32c7dc5bc863@github.com>

On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to use C++17 for building C++ parts of the JDK. In
>> particular this affects HotSpot. This change also includes an update to the
>> HotSpot Style Guide regarding C++17 features and their use in HotSpot code.
>> 
>> Testing: mach5 tier1-8
>> 
>> This change includes a modification of the Style Guide. Rough consensus among
>> the HotSpot Group members is required to make such a change. Only Group
>> members should vote for approval (via the github PR), though reasoned
>> objections or comments from anyone will be considered. A decision on this
>> proposal will not be made before Friday 5-September-2025 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review process
>> to approve (click on Review Changes > Approve), rather than sending a "vote:
>> yes" email reply that would be normal for a CFV.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing word
>  - stefank suggestions

Thanks for your comments and approvals.

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

PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3259707171

From kbarrett at openjdk.org  Fri Sep  5 20:50:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 5 Sep 2025 20:50:24 GMT
Subject: Integrated: 8314488: Compiling the JDK with C++17
In-Reply-To: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
Message-ID: <hjfKWjUZc2TkYA_slKPd1RPfakesfi1qhKfSOW8UGDc=.385cf9bc-7efc-4bb5-a758-a037e8bf3150@github.com>

On Thu, 21 Aug 2025 14:47:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to use C++17 for building C++ parts of the JDK. In
> particular this affects HotSpot. This change also includes an update to the
> HotSpot Style Guide regarding C++17 features and their use in HotSpot code.
> 
> Testing: mach5 tier1-8
> 
> This change includes a modification of the Style Guide. Rough consensus among
> the HotSpot Group members is required to make such a change. Only Group
> members should vote for approval (via the github PR), though reasoned
> objections or comments from anyone will be considered. A decision on this
> proposal will not be made before Friday 5-September-2025 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

This pull request has now been integrated.

Changeset: 1ebe9495
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ebe949507b48a6b62dd36e08f0ae80da2ee1dcc
Stats:     1186 lines in 7 files changed: 1098 ins; 35 del; 53 mod

8314488: Compiling the JDK with C++17

Reviewed-by: dholmes, stefank, ayang, kvn, iwalulya, jsjolen, ihse

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

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

From liach at openjdk.org  Fri Sep  5 21:11:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 21:11:21 GMT
Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on
 build [v2]
In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
 <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com>
Message-ID: <5-Zn_EAg4aWyL6DL9NzACsKHP_JtOxk-CbH4nA4BVN8=.6666d403-4d31-4cd4-92fd-87b055e792ce@github.com>

On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
>> 
>> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
>> 
>> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
>> 
>> <details>
>> <summary>
>> Diff from new to old (backwards):
>> </summary>
>> 
>> 
>> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> index 13ef65b..49408a2 100644
>> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
>> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
>> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>>  import jdk.internal.vm.annotation.ForceInline;
>>  import jdk.internal.vm.annotation.Hidden;
>>  
>> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
>> -// Do not edit!
>> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>>  @AOTSafeClassInitializer
>>  final class VarHandleGuards {
>>  
>> 
>> 
>> </details>
>> 
>> Testing: java/lang/invoke.
>
> Chen Liang 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:
> 
>  - Preexisting typos
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards
>  - Restore order
>  - 8366455: Move VarHandles.GuardMethodGenerator to execute on build

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3259748920

From liach at openjdk.org  Fri Sep  5 21:11:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 Sep 2025 21:11:22 GMT
Subject: Integrated: 8366455: Move VarHandles.GuardMethodGenerator to execute
 on build
In-Reply-To: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
References: <Zt_6JsMVPiOgocL1D43K_YD8e7Qt_WHapIcQck__Rt0=.cb2152c0-7e84-4112-99d3-4177ebf4db27@github.com>
Message-ID: <FkZNO9eUJAbjrTJdNSXw8niPEZrAdfH_F4ZGhVOaFC0=.cbfef0eb-bf08-4572-9e49-90d8619eeeb3@github.com>

On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
> 
> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
> 
> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
> 
> <details>
> <summary>
> Diff from new to old (backwards):
> </summary>
> 
> 
> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> index 13ef65b..49408a2 100644
> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.Hidden;
>  
> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
> -// Do not edit!
> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>  @AOTSafeClassInitializer
>  final class VarHandleGuards {
>  
> 
> 
> </details>
> 
> Testing: java/lang/invoke.

This pull request has now been integrated.

Changeset: cdc8b5eb
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cdc8b5eb83ed6335a65b93cfa0cf38932486c7e3
Stats:     2197 lines in 5 files changed: 340 ins; 1857 del; 0 mod

8366455: Move VarHandles.GuardMethodGenerator to execute on build

Reviewed-by: psandoz, redestad, erikj

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

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

From erikj at openjdk.org  Fri Sep  5 22:44:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 22:44:11 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <eCl70feNMDZHPsLXYkDl5_eTX0kmmuwHWn8IOts1Ngs=.99a0a13e-c3a9-4255-b3e5-c93fec30fe71@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

make/modules/java.base/gensrc/GensrcBuffer.gmk line 162:

> 160: 	$$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp
> 161: 	$$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp
> 162: 	$$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT)

Indentation looks off here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326173444

From erikj at openjdk.org  Fri Sep  5 22:47:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 22:47:09 GMT
Subject: RFR: 8332872: SetupExecute should cd to temp directory
In-Reply-To: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
References: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
Message-ID: <4XeqEZASLItx5qh80Gn-nqV__2yoCWSnHy6oqAI_3h4=.dedb9469-9096-4f8f-bab6-018f3bffa998@github.com>

On Thu, 4 Sep 2025 15:34:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some commands create junk files all around in the current directory. We should change directory to a special working dir (typically the support dir) in SetupExecute, before running any command.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27103#pullrequestreview-3190987516

From ihse at openjdk.org  Fri Sep  5 22:50:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Sep 2025 22:50:11 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <eCl70feNMDZHPsLXYkDl5_eTX0kmmuwHWn8IOts1Ngs=.99a0a13e-c3a9-4255-b3e5-c93fec30fe71@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <eCl70feNMDZHPsLXYkDl5_eTX0kmmuwHWn8IOts1Ngs=.99a0a13e-c3a9-4255-b3e5-c93fec30fe71@github.com>
Message-ID: <XaASIt9fTbzgwmTb5BOuogCyvg1Kxy504J-397aDqi4=.3276ee60-9ffb-4519-8db7-28ce5a53907f@github.com>

On Fri, 5 Sep 2025 22:34:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.
>
> make/modules/java.base/gensrc/GensrcBuffer.gmk line 162:
> 
>> 160: 	$$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp
>> 161: 	$$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp
>> 162: 	$$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT)
> 
> Indentation looks off here.

I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326185455

From liach at openjdk.org  Sat Sep  6 01:07:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 Sep 2025 01:07:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v4]
In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
Message-ID: <kGpi3aYzYwRbiMB5tsFl5lKfW8CrsfyTfdWFC32t7J4=.d197b722-3af1-467f-9746-ac5d7f6d1714@github.com>

On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

#26749 was merged 4 days ago. Can we integrate this one now?

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3260152639

From alanb at openjdk.org  Sat Sep  6 07:04:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Sep 2025 07:04:14 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v4]
In-Reply-To: <kGpi3aYzYwRbiMB5tsFl5lKfW8CrsfyTfdWFC32t7J4=.d197b722-3af1-467f-9746-ac5d7f6d1714@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
 <kGpi3aYzYwRbiMB5tsFl5lKfW8CrsfyTfdWFC32t7J4=.d197b722-3af1-467f-9746-ac5d7f6d1714@github.com>
Message-ID: <YxpglJeFctRS7YHypdv7gXRIEKlPspolydCqlcVyzwc=.7ab1ceb7-b5d9-40ff-8de4-3ae176112fde@github.com>

On Sat, 6 Sep 2025 01:04:56 GMT, Chen Liang <liach at openjdk.org> wrote:

> #26749 was merged 4 days ago. Can we integrate this one now?

I think it would be useful to get input from @dholmes-ora and @lkorinth before doing this.  There seems to be several timeout issues in the last few days, a few follow-on changes to adjust the timeout of a few tests, and a spate of tests being reported as timed out after passing.  Updating jtreg adds another change to the picture.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3261436239

From ihse at openjdk.org  Sat Sep  6 09:03:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 6 Sep 2025 09:03:19 GMT
Subject: Integrated: 8332872: SetupExecute should cd to temp directory
In-Reply-To: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
References: <kWMGC3FLF3UOBoz_wzaz-UWj0-_MURaXnjWqMxj9BBU=.f021636d-3470-4eb6-9c0f-c580abfbab99@github.com>
Message-ID: <XtQj4cNKiLiC8olRQtiwRmJ1MI93F9g_OEiI5x66FaQ=.36252f73-b6fe-4dc7-9bc9-47595e183025@github.com>

On Thu, 4 Sep 2025 15:34:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some commands create junk files all around in the current directory. We should change directory to a special working dir (typically the support dir) in SetupExecute, before running any command.

This pull request has now been integrated.

Changeset: e8c7d2aa
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8c7d2aaf3cdbbe07b8cdcc68dd7ec9645956bf2
Stats:     101 lines in 5 files changed: 86 ins; 0 del; 15 mod

8332872: SetupExecute should cd to temp directory

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Sat Sep  6 09:05:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 6 Sep 2025 09:05:10 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <XaASIt9fTbzgwmTb5BOuogCyvg1Kxy504J-397aDqi4=.3276ee60-9ffb-4519-8db7-28ce5a53907f@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <eCl70feNMDZHPsLXYkDl5_eTX0kmmuwHWn8IOts1Ngs=.99a0a13e-c3a9-4255-b3e5-c93fec30fe71@github.com>
 <XaASIt9fTbzgwmTb5BOuogCyvg1Kxy504J-397aDqi4=.3276ee60-9ffb-4519-8db7-28ce5a53907f@github.com>
Message-ID: <ShGbfs_kZPO4QUnNwvPXvomACi8rHi2FipbM2ykhjVo=.60114632-9119-4ff5-9cde-6fdbb3b3a940@github.com>

On Fri, 5 Sep 2025 22:47:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/gensrc/GensrcBuffer.gmk line 162:
>> 
>>> 160: 	$$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp
>>> 161: 	$$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp
>>> 162: 	$$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT)
>> 
>> Indentation looks off here.
>
> I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect.

Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326684556

From ihse at openjdk.org  Sat Sep  6 09:15:47 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 6 Sep 2025 09:15:47 GMT
Subject: RFR: 8330341: Wrap call to MT in ExecuteWithLog
Message-ID: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>

We should wrap the call to `mt` in `ExecuteWithLog`. I tried to do this earlier but ran into problems with the tricky command line. The solution was to use `$$(COMMA)` (and `$$(HASH)`); I'm not sure why I did not see this before.

I also notet that there is an actual bug in the MT command line -- the trailing `;#1` is not protected from the shell, so the command line will end after `-outputresource:$$@`, and then a new command -- the comment `#1` which does nothing, will be executed. This works out anyway since if you leave out the resource identifier index the value of `CREATEPROCESS_MANIFEST_RESOURCE` will be used by default, and that happens to be 1.
 (See https://learn.microsoft.com/en-us/windows/win32/sbscs/mt-exe)

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

Commit messages:
 - 8330341: Wrap call to MT in ExecuteWithLog

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

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

From ihse at openjdk.org  Sat Sep  6 09:15:47 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 6 Sep 2025 09:15:47 GMT
Subject: RFR: 8330341: Wrap call to MT in ExecuteWithLog
In-Reply-To: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
References: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
Message-ID: <QHAsrFj8cKZbP3pelx1dftyfSrNcuIXBgNw3NfUDpEY=.e8fae812-5fcb-4196-9c0a-113fb3ea7a90@github.com>

On Fri, 5 Sep 2025 17:08:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should wrap the call to `mt` in `ExecuteWithLog`. I tried to do this earlier but ran into problems with the tricky command line. The solution was to use `$$(COMMA)` (and `$$(HASH)`); I'm not sure why I did not see this before.
> 
> I also notet that there is an actual bug in the MT command line -- the trailing `;#1` is not protected from the shell, so the command line will end after `-outputresource:$$@`, and then a new command -- the comment `#1` which does nothing, will be executed. This works out anyway since if you leave out the resource identifier index the value of `CREATEPROCESS_MANIFEST_RESOURCE` will be used by default, and that happens to be 1.
>  (See https://learn.microsoft.com/en-us/windows/win32/sbscs/mt-exe)

I have done a comparison build on the Oracle CI and confirmed that the build output is identical with and without this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/27124#issuecomment-3261667149

From syan at openjdk.org  Sun Sep  7 14:07:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 7 Sep 2025 14:07:16 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
Message-ID: <Oyb7ajBYNKtR3pnckFxstsIUmiFBum8EoG5EeMy53vc=.710ff2ba-0f5a-4b92-9d0d-f5237f9fd67d@github.com>

On Fri, 5 Sep 2025 12:56:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE
>
> make/autoconf/flags-cflags.m4 line 996:
> 
>> 994: AC_DEFUN([BPERF_SETUP_SVE],
>> 995: [
>> 996:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
> 
> The idea with this macro is that you put the supported check and actions on enabled/disabled in the call and let it handle the logic. It shouldn't be moved to a separate macro. Also, macros defined in this file should have the `FLAGS` prefix, not `BPERF`.

I also want to put the put the supported check and actions on enabled/disabled in the call previous. But I found that the configure will stuck at below command:


++ /usr/bin/autoconf -W all -I/home/yansendao/git/jdk-ysd/make/autoconf -


The change like that:


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index 97e37cc923b..96ea730e80a 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -940,6 +940,10 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
   # ACLE and this flag are required to build the aarch64 SVE related functions in
   # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
   # that check.
+  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
+      RESULT: enable_aarch64_sve,
+      DESC: [Use SVE when compile libsleef])
+  AC_SUBST(enable_aarch64_sve)
   if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
     if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
       AC_LANG_PUSH(C)
@@ -991,14 +995,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
   AC_SUBST($2SVE_CFLAGS)
 ])

-AC_DEFUN([BPERF_SETUP_SVE],
-[
-  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
-      RESULT: enable_aarch64_sve,
-      DESC: [Use SVE when compile libsleef])
-  AC_SUBST(enable_aarch64_sve)
-])
-
 AC_DEFUN_ONCE([FLAGS_SETUP_BRANCH_PROTECTION],
 [
   # Is branch protection available?


I think I should find other solution later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2328699427

From dholmes at openjdk.org  Sun Sep  7 20:16:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 7 Sep 2025 20:16:08 GMT
Subject: RFR: 8367035: [BACKOUT] Protect ExecuteWithLog from running with
 redirection without a subshell
Message-ID: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>

Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell"

This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8.

Thanks

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

Commit messages:
 - Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell"

Changes: https://git.openjdk.org/jdk/pull/27132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367035
  Stats: 41 lines in 5 files changed: 5 ins; 14 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27132/head:pull/27132

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

From kbarrett at openjdk.org  Sun Sep  7 20:24:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 7 Sep 2025 20:24:14 GMT
Subject: RFR: 8367035: [BACKOUT] Protect ExecuteWithLog from running with
 redirection without a subshell
In-Reply-To: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>
References: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>
Message-ID: <XVNGp4-pEcvd2uVDfecav7RPv1iCr0qQ4Iskth5x084=.3b597497-e4a7-42b8-b4d7-6af84c729589@github.com>

On Sun, 7 Sep 2025 20:08:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell"
> 
> This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8.
> 
> Thanks

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27132#pullrequestreview-3194576852

From dholmes at openjdk.org  Sun Sep  7 20:24:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 7 Sep 2025 20:24:15 GMT
Subject: RFR: 8367035: [BACKOUT] Protect ExecuteWithLog from running with
 redirection without a subshell
In-Reply-To: <XVNGp4-pEcvd2uVDfecav7RPv1iCr0qQ4Iskth5x084=.3b597497-e4a7-42b8-b4d7-6af84c729589@github.com>
References: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>
 <XVNGp4-pEcvd2uVDfecav7RPv1iCr0qQ4Iskth5x084=.3b597497-e4a7-42b8-b4d7-6af84c729589@github.com>
Message-ID: <1V-bFmUKAa4eO04lhEYGujfZcSJlJEXK_2TZQ8ben5c=.d0acf3ec-6d7a-4661-ada3-093c7b260c0a@github.com>

On Sun, 7 Sep 2025 20:17:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell"
>> 
>> This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8.
>> 
>> Thanks
>
> Looks good.

Thanks @kimbarrett !

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

PR Comment: https://git.openjdk.org/jdk/pull/27132#issuecomment-3264018015

From dholmes at openjdk.org  Sun Sep  7 20:24:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 7 Sep 2025 20:24:15 GMT
Subject: Integrated: 8367035: [BACKOUT] Protect ExecuteWithLog from running
 with redirection without a subshell
In-Reply-To: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>
References: <qg2dZZtSQUUpvyvoAOU5KtLF1kbSxtH7XTnamtruiDs=.b8317a5d-48f1-4a55-811c-38e834e16d91@github.com>
Message-ID: <r7iKcp2YoNck4BGNjOX3zpjpCWSmtxQ0mXQR_h1TjPU=.1b642a8e-b58b-410c-bbe2-14d342526e09@github.com>

On Sun, 7 Sep 2025 20:08:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8233115: Protect ExecuteWithLog from running with redirection without a subshell"
> 
> This reverts commit 124fcf1d9abb6cafe34637ba357617c7c7be56c8.
> 
> Thanks

This pull request has now been integrated.

Changeset: 6bb15a54
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bb15a542b0eb6a4b17cfd9da50a94781d0180eb
Stats:     41 lines in 5 files changed: 5 ins; 14 del; 22 mod

8367035: [BACKOUT] Protect ExecuteWithLog from running with redirection without a subshell

Reviewed-by: kbarrett

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

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

From dholmes at openjdk.org  Mon Sep  8 04:27:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 Sep 2025 04:27:19 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v4]
In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
Message-ID: <Hlof_5ZD-85FCUw0TyvVF4VGTvGvbQnBoibCyJskWeU=.2450d8ee-3863-4f71-8da5-79ce6bf0e61d@github.com>

On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

I would appreciate it if this could hold off a while longer as we have a few issues causing noise in our testing at the moment and I don't want to muddy the waters even further. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3264544890

From ihse at openjdk.org  Mon Sep  8 11:39:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Sep 2025 11:39:49 GMT
Subject: RFR: 8367034: [REDO] Protect ExecuteWithLog from running with
 redirection without a subshell
Message-ID: <SRWovVQZDa5020NTfCsP9HTz21Ka25jE8fODOrne4og=.10bee4af-7505-4c85-be20-68af0a5f33e6@github.com>

This is a redo of [JDK-8233115](https://bugs.openjdk.org/browse/JDK-8233115). The problem was that some of the AOT test command lines had `,` in them. Since this is interpreted as argument separator by make, it is not allowed, and it should be escaped to `$(COMMA)`. 

However, it seems like the GNU make parser did not consider `,` to be an argument parser if it was nested inside matching `(` ... `)`, and so by pure luck it worked anyway, until I removed those subshell parentheses.

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

Commit messages:
 - 8367034: [REDO] Protect ExecuteWithLog from running with redirection without a subshell

Changes: https://git.openjdk.org/jdk/pull/27140/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367034
  Stats: 44 lines in 5 files changed: 14 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/27140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27140/head:pull/27140

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

From erikj at openjdk.org  Mon Sep  8 13:20:19 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 13:20:19 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <wUOqLW_iStzyqvLKPBB2KSHGvVGrqg37-t8-r5ZwnlA=.ea5a814a-9d5b-44b6-ad60-9ff64b5c699e@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27078#pullrequestreview-3196501441

From erikj at openjdk.org  Mon Sep  8 13:20:21 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 13:20:21 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <ShGbfs_kZPO4QUnNwvPXvomACi8rHi2FipbM2ykhjVo=.60114632-9119-4ff5-9cde-6fdbb3b3a940@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <eCl70feNMDZHPsLXYkDl5_eTX0kmmuwHWn8IOts1Ngs=.99a0a13e-c3a9-4255-b3e5-c93fec30fe71@github.com>
 <XaASIt9fTbzgwmTb5BOuogCyvg1Kxy504J-397aDqi4=.3276ee60-9ffb-4519-8db7-28ce5a53907f@github.com>
 <ShGbfs_kZPO4QUnNwvPXvomACi8rHi2FipbM2ykhjVo=.60114632-9119-4ff5-9cde-6fdbb3b3a940@github.com>
Message-ID: <adBTkhwP2v0R9lt60CwrzbZVJZjTB5YpSfPE0UTxLdw=.dc585924-bb77-4d70-9545-381522653191@github.com>

On Sat, 6 Sep 2025 09:02:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect.
>
> Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance.

You are right, thanks for that link!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2330222469

From erikj at openjdk.org  Mon Sep  8 13:22:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 13:22:15 GMT
Subject: RFR: 8330341: Wrap call to MT in ExecuteWithLog
In-Reply-To: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
References: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
Message-ID: <81laLe1YOmZ77MO0gBVtqT6b1dWrKJP1gDOKJqhwGxQ=.bcfae1dc-e377-4ec2-a202-e713787f2aea@github.com>

On Fri, 5 Sep 2025 17:08:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should wrap the call to `mt` in `ExecuteWithLog`. I tried to do this earlier but ran into problems with the tricky command line. The solution was to use `$$(COMMA)` (and `$$(HASH)`); I'm not sure why I did not see this before.
> 
> I also noted that there is an actual bug in the MT command line -- the trailing `;#1` is not protected from the shell, so the command line will end after `-outputresource:$$@`, and then a new command -- the comment `#1` which does nothing, will be executed. This works out anyway since if you leave out the resource identifier index the value of `CREATEPROCESS_MANIFEST_RESOURCE` will be used by default, and that happens to be 1.
>  (See https://learn.microsoft.com/en-us/windows/win32/sbscs/mt-exe)

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27124#pullrequestreview-3196507421

From erikj at openjdk.org  Mon Sep  8 13:24:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 13:24:10 GMT
Subject: RFR: 8367034: [REDO] Protect ExecuteWithLog from running with
 redirection without a subshell
In-Reply-To: <SRWovVQZDa5020NTfCsP9HTz21Ka25jE8fODOrne4og=.10bee4af-7505-4c85-be20-68af0a5f33e6@github.com>
References: <SRWovVQZDa5020NTfCsP9HTz21Ka25jE8fODOrne4og=.10bee4af-7505-4c85-be20-68af0a5f33e6@github.com>
Message-ID: <OJzEOXBGwAX5nqTTE1KCu13MBZBpSFQDuoZyAjabi3c=.4dadb9d2-3fac-4cf7-8941-3e3c35fcc06c@github.com>

On Mon, 8 Sep 2025 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a redo of [JDK-8233115](https://bugs.openjdk.org/browse/JDK-8233115). The problem was that some of the AOT test command lines had `,` in them. Since this is interpreted as argument separator by make, it is not allowed, and it should be escaped to `$(COMMA)`. 
> 
> However, it seems like the GNU make parser did not consider `,` to be an argument parser if it was nested inside matching `(` ... `)`, and so by pure luck it worked anyway, until I removed those subshell parentheses.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27140#pullrequestreview-3196520667

From jwaters at openjdk.org  Mon Sep  8 14:25:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Sep 2025 14:25:02 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt [v2]
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <w2GY_LELcDSASTQJyGrbmh3vZ4x4hHO9gpUJsnOVm7A=.97df38cf-929b-4596-9c53-28afa212e34d@github.com>

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

Julian Waters 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 awt
 - 8342869

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21655/files
  - new: https://git.openjdk.org/jdk/pull/21655/files/ee4d1bb5..90903171

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

  Stats: 1560860 lines in 20249 files changed: 770956 ins; 654744 del; 135160 mod
  Patch: https://git.openjdk.org/jdk/pull/21655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21655/head:pull/21655

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

From jwaters at openjdk.org  Mon Sep  8 14:28:27 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Sep 2025 14:28:27 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt [v2]
In-Reply-To: <w2GY_LELcDSASTQJyGrbmh3vZ4x4hHO9gpUJsnOVm7A=.97df38cf-929b-4596-9c53-28afa212e34d@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
 <w2GY_LELcDSASTQJyGrbmh3vZ4x4hHO9gpUJsnOVm7A=.97df38cf-929b-4596-9c53-28afa212e34d@github.com>
Message-ID: <nayv3WZQNnwYhMd0EdVNFlxvBX0K73qWiqgRf6kKRrI=.df3084d8-46ac-424b-8746-647adfd6aee6@github.com>

On Mon, 8 Sep 2025 14:25:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>> 
>> build.log on release configuration:
>> 
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>>       |                                       ^~~~~~~~~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>>  1361 | } SUBTABLE, *PSUBTABLE;
>>       |              ^~~~~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>>  1588 | } HEAD, *PHEAD;
>>       |          ^~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>>  1595 | } ENTRY, *PENTRY;
>>       |           ^~~~~~
>> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/w...
>
> Julian Waters 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 awt
>  - 8342869

Hi Phil, would it help if I split out the moving of DrawingStateProp to the C++ file to another Pull Request? Majority of this Pull Request is dead constants and the remainder are things that are needed but will raise an unused error anyway (Like the struct typedefs)

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

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-3266585629

From ihse at openjdk.org  Mon Sep  8 16:49:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Sep 2025 16:49:25 GMT
Subject: Integrated: 8367034: [REDO] Protect ExecuteWithLog from running with
 redirection without a subshell
In-Reply-To: <SRWovVQZDa5020NTfCsP9HTz21Ka25jE8fODOrne4og=.10bee4af-7505-4c85-be20-68af0a5f33e6@github.com>
References: <SRWovVQZDa5020NTfCsP9HTz21Ka25jE8fODOrne4og=.10bee4af-7505-4c85-be20-68af0a5f33e6@github.com>
Message-ID: <5bcWIIy6PTX6tkm_vaW8uuI1HXSucOmGfeH1Eh8mQsY=.88ad5271-f0b5-4b71-9404-29a9b7649bb6@github.com>

On Mon, 8 Sep 2025 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a redo of [JDK-8233115](https://bugs.openjdk.org/browse/JDK-8233115). The problem was that some of the AOT test command lines had `,` in them. Since this is interpreted as argument separator by make, it is not allowed, and it should be escaped to `$(COMMA)`. 
> 
> However, it seems like the GNU make parser did not consider `,` to be an argument parser if it was nested inside matching `(` ... `)`, and so by pure luck it worked anyway, until I removed those subshell parentheses.

This pull request has now been integrated.

Changeset: 323b0201
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/323b02016e7458a0be39d52c9b0a5c61d579347e
Stats:     44 lines in 5 files changed: 14 ins; 5 del; 25 mod

8367034: [REDO] Protect ExecuteWithLog from running with redirection without a subshell

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Sep  8 16:51:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Sep 2025 16:51:21 GMT
Subject: Integrated: 8330341: Wrap call to MT in ExecuteWithLog
In-Reply-To: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
References: <yJREkBLY1ntxZnDcOBVgfFFb0wzcocYoKzvwQ_7BeQY=.87d7bedc-5f43-4fa0-a6ca-927ea06be8b8@github.com>
Message-ID: <aRIEwYM2iET1rNR-LeRQkUZY8bSk9CliE7Veq-ijCvU=.3b28b07f-c08b-4b2a-ad79-e66f865a0a11@github.com>

On Fri, 5 Sep 2025 17:08:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should wrap the call to `mt` in `ExecuteWithLog`. I tried to do this earlier but ran into problems with the tricky command line. The solution was to use `$$(COMMA)` (and `$$(HASH)`); I'm not sure why I did not see this before.
> 
> I also noted that there is an actual bug in the MT command line -- the trailing `;#1` is not protected from the shell, so the command line will end after `-outputresource:$$@`, and then a new command -- the comment `#1` which does nothing, will be executed. This works out anyway since if you leave out the resource identifier index the value of `CREATEPROCESS_MANIFEST_RESOURCE` will be used by default, and that happens to be 1.
>  (See https://learn.microsoft.com/en-us/windows/win32/sbscs/mt-exe)

This pull request has now been integrated.

Changeset: cb58e656
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb58e6560a3b80655224cb79d52bfd0afa3cf262
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8330341: Wrap call to MT in ExecuteWithLog

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Sep  8 16:51:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 8 Sep 2025 16:51:23 GMT
Subject: Integrated: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <F4Qx927r-eDtADy59px1W6jarXdK5PlHaLHnaDYZVCU=.a4ff54eb-1e8d-4c76-9f9f-735f53a33eb5@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

This pull request has now been integrated.

Changeset: 55af9d83
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55af9d83800930966776224bc4c7ff4ab1af9817
Stats:     1321 lines in 9 files changed: 523 ins; 562 del; 236 mod

8366837: Clean up gensrc by spp.Spp

Reviewed-by: erikj

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

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

From duke at openjdk.org  Mon Sep  8 18:00:20 2025
From: duke at openjdk.org (xxDark)
Date: Mon, 8 Sep 2025 18:00:20 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <D3A_ZkEzQWNmPxfI4WygVyZX4T8bqg3bM4p8yxYe4xA=.c898bc65-db42-476e-8fb5-de6db9526176@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

Hello, this seemingly broke the build on Windows x64.
VarHandleGuards class does not get generated.

                             ^
f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol
                    VarHandleGuards.class, getVarHandleGuardMethodName(guardType),
                    ^
  symbol:   class VarHandleGuards
  location: class MethodHandleNatives
f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol
                                                           VarHandleGuards.class, LM_TRUSTED);
                                                           ^
  symbol:   class VarHandleGuards
  location: class MethodHandleNatives
f:\openjdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol
        UNSAFE.ensureClassInitialized(VarHandleGuards.class)
        

Reverting this commit fixed the issue.
The setup to configure the build was as follows:

set JAVA_HOME=D:\jdks\temurin-24.0.32
d:\MSV2019\VC\Auxiliary\Build\vcvars64.bat
d:\cygwin64\Cygwin.bat
cd /cygdrive/f/openjdk
bash configure
make java.base



$ make clean java.base
Building targets 'clean java.base' in configuration 'windows-x86_64-server-release'
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning test-results build artifacts ... done
Cleaning test-support build artifacts ... done
Cleaning test build artifacts ... done
Cleaning buildtools build artifacts ... done
Cleaning support build artifacts ... done
Cleaning support/images build artifacts ... done
Cleaning images build artifacts ... done
Cleaning make-support build artifacts ... done
Cleaning test-make build artifacts ... done
Cleaning bundles build artifacts ... done
Cleaning buildjdk build artifacts ... done
Cleaned all build artifacts.
Compiling up to 1 files for BUILD_TOOLS_HOTSPOT
Compiling up to 9 files for BUILD_TOOLS_LANGTOOLS
Generating classes for compiler.properties launcher.properties
Compiling 17 properties into resource bundles for jdk.javadoc
Generating FlagsEnum
Compiling 19 properties into resource bundles for jdk.compiler
Compiling up to 136 files for BUILD_java.compiler.interim
Compiling up to 360 files for BUILD_jdk.compiler.interim
Compiling up to 145 files for BUILD_jdk.internal.md.interim
Compiling up to 213 files for BUILD_jdk.javadoc.interim
Compiling up to 17 files for BUILD_JAVAC_SERVER
Compiling up to 190 files for BUILD_TOOLS_JDK
Compiling up to 2 files for COMPILE_DEPEND
Compiling up to 2 files for BUILD_BREAKITERATOR_BASE
Compiling up to 2 files for BUILD_BREAKITERATOR_LD
SocketOptionRegistry.java.template
d:\msvwin10kit\include\10.0.19041.0\um\winbase.h(9531): warning C5105: macro expansion producing 'defined' has undefined behavior
Compiling 11 properties into resource bundles for java.base
Compiling 3 properties into resource bundles for java.base
Compiling 22 properties into resource bundles for java.base
Compiling 11 properties into resource bundles for java.base
Compiling up to 3366 files for java.base
Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s)
Compiling up to 2 files for BUILD_JVMTI_TOOLS
Creating support/modules_libs/java.base/server/jvm.dll from 1223 file(s)
f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol
                    VarHandleGuards.class, getVarHandleGuardMethodName(guardType),
                    ^
  symbol:   class VarHandleGuards
  location: class MethodHandleNatives
f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol
                                                           VarHandleGuards.class, LM_TRUSTED);
                                                           ^
  symbol:   class VarHandleGuards
  location: class MethodHandleNatives
f:\jdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol
        UNSAFE.ensureClassInitialized(VarHandleGuards.class);
                                      ^
  symbol:   class VarHandleGuards
  location: class VarHandle
3 errors
make[3]: *** [CompileJavaModules.gmk:102: /cygdrive/f/jdk/build/windows-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1
make[2]: *** [make/Main.gmk:182: java.base-java] Error 2
make[2]: *** Waiting for unfinished jobs....

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

PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267328044

From liach at openjdk.org  Mon Sep  8 18:09:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Sep 2025 18:09:18 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
Message-ID: <RH2VJXXLu4e3uDpsC4Kd7hUFDj98RPmUtIgKWaOyNPI=.e5795593-cb4c-437d-bc80-ae54af9aa34d@github.com>

On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up.

This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267361378

From alanb at openjdk.org  Mon Sep  8 18:27:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Sep 2025 18:27:19 GMT
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <RH2VJXXLu4e3uDpsC4Kd7hUFDj98RPmUtIgKWaOyNPI=.e5795593-cb4c-437d-bc80-ae54af9aa34d@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <RH2VJXXLu4e3uDpsC4Kd7hUFDj98RPmUtIgKWaOyNPI=.e5795593-cb4c-437d-bc80-ae54af9aa34d@github.com>
Message-ID: <YVmjCxaDcN-jm8nsQcNJr09e16VQj9CdY5GAae0N1Ow=.6671e0bd-e25d-4dd0-bd9e-587794bc29a3@github.com>

On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix.

I think the change needs to backed out and the differences with line numbers checked to see what impact it will have on stack traces and mapping it back to the sources in the template files.

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

PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085

From philip.race at oracle.com  Mon Sep  8 18:52:43 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 8 Sep 2025 11:52:43 -0700
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <YVmjCxaDcN-jm8nsQcNJr09e16VQj9CdY5GAae0N1Ow=.6671e0bd-e25d-4dd0-bd9e-587794bc29a3@github.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <RH2VJXXLu4e3uDpsC4Kd7hUFDj98RPmUtIgKWaOyNPI=.e5795593-cb4c-437d-bc80-ae54af9aa34d@github.com>
 <YVmjCxaDcN-jm8nsQcNJr09e16VQj9CdY5GAae0N1Ow=.6671e0bd-e25d-4dd0-bd9e-587794bc29a3@github.com>
Message-ID: <d8ca2443-8552-4947-95e4-33dee5b9daaf@oracle.com>

Looks like it broke all the builds. So a P1 backout is needed.

-phil.

On 9/8/25 11:27 AM, Alan Bateman wrote:
> On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>> This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix.
> I think the change needs to backed out and the differences with line numbers checked to see what impact it will have on stack traces and mapping it back to the sources in the template files.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085


From philip.race at oracle.com  Mon Sep  8 19:10:47 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 8 Sep 2025 12:10:47 -0700
Subject: RFR: 8366837: Clean up gensrc by spp.Spp
In-Reply-To: <d8ca2443-8552-4947-95e4-33dee5b9daaf@oracle.com>
References: <U8nNf7n-YsnKxs9-0nIB5vgq1Dp1Y7kZ4WF8Rk3U-Js=.16b5a154-3c95-4c18-915f-51616f650d52@github.com>
 <RH2VJXXLu4e3uDpsC4Kd7hUFDj98RPmUtIgKWaOyNPI=.e5795593-cb4c-437d-bc80-ae54af9aa34d@github.com>
 <YVmjCxaDcN-jm8nsQcNJr09e16VQj9CdY5GAae0N1Ow=.6671e0bd-e25d-4dd0-bd9e-587794bc29a3@github.com>
 <d8ca2443-8552-4947-95e4-33dee5b9daaf@oracle.com>
Message-ID: <311b7575-95d9-45e1-8146-bf9dd77dc2da@oracle.com>

I submitted a bug report : https://bugs.openjdk.org/browse/JDK-8367130

-phil.

On 9/8/25 11:52 AM, Philip Race wrote:
> Looks like it broke all the builds. So a P1 backout is needed.
>
> -phil.
>
> On 9/8/25 11:27 AM, Alan Bateman wrote:
>> On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang <liach at openjdk.org> wrote:
>>
>>> This patch removed the `VARHANDLES_GENSRC_DIR` variable used by 
>>> VarHandleGuards generation. I think it can be addressed by a hot fix.
>> I think the change needs to backed out and the differences with line 
>> numbers checked to see what impact it will have on stack traces and 
>> mapping it back to the sources in the template files.
>>
>> -------------
>>
>> PR Comment: 
>> https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085
>


From erikj at openjdk.org  Mon Sep  8 19:57:21 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 19:57:21 GMT
Subject: RFR: 8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp
Message-ID: <BDVl52rQZiOLQt4btNvCJDNlmpk71Uos3qVOoiT0dQg=.52d142a8-af3e-425a-9e82-0179bb883e99@github.com>

Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455).  The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name.

I'm running a quick verification in internal CI.

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

Commit messages:
 - JDK-8367130

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

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

From liach at openjdk.org  Mon Sep  8 20:16:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Sep 2025 20:16:10 GMT
Subject: RFR: 8367130: JDK builds broken by 8366837: Clean up gensrc by
 spp.Spp
In-Reply-To: <BDVl52rQZiOLQt4btNvCJDNlmpk71Uos3qVOoiT0dQg=.52d142a8-af3e-425a-9e82-0179bb883e99@github.com>
References: <BDVl52rQZiOLQt4btNvCJDNlmpk71Uos3qVOoiT0dQg=.52d142a8-af3e-425a-9e82-0179bb883e99@github.com>
Message-ID: <KjLCkGpZg2WpFOIC6X-Xxs2Jl_PvDX2H3n1_3E_pFEI=.f328d0fc-d029-4ede-9502-a483b365be9c@github.com>

On Mon, 8 Sep 2025 19:50:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455).  The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name.
> 
> I'm running a quick verification in internal CI.

Thanks for this quick fix. We can investigate generated class parity later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27150#pullrequestreview-3197998413

From erikj at openjdk.org  Mon Sep  8 20:55:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 20:55:15 GMT
Subject: Integrated: 8367130: JDK builds broken by 8366837: Clean up gensrc by
 spp.Spp
In-Reply-To: <BDVl52rQZiOLQt4btNvCJDNlmpk71Uos3qVOoiT0dQg=.52d142a8-af3e-425a-9e82-0179bb883e99@github.com>
References: <BDVl52rQZiOLQt4btNvCJDNlmpk71Uos3qVOoiT0dQg=.52d142a8-af3e-425a-9e82-0179bb883e99@github.com>
Message-ID: <sU-xkS87e98JFnrpYo2ci8tF7GVanN1ObiyJwdDiGi4=.66c85128-6f5c-40b4-bbe9-ee36b4b2c224@github.com>

On Mon, 8 Sep 2025 19:50:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455).  The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name.
> 
> I'm running a quick verification in internal CI.

This pull request has now been integrated.

Changeset: 56e37352
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56e37352d5b0a749ccd150c36c9248e37d280eb6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp

Reviewed-by: liach

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

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

From ihse at openjdk.org  Tue Sep  9 07:09:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 07:09:16 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
Message-ID: <I3c5whe2bvIz0zCU0qKWFtBSo-QYnp6yiBZ6Rkc4yJU=.a9c659a0-82db-4be7-b260-ae6edccb7b92@github.com>

On Fri, 5 Sep 2025 06:16:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE

make/autoconf/flags-cflags.m4 line 994:

> 992: ])
> 993: 
> 994: AC_DEFUN([BPERF_SETUP_SVE],

The `BPERF_` prefix says that this function belongs to build-performance.m4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2332244788

From ihse at openjdk.org  Tue Sep  9 07:14:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 07:14:16 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
Message-ID: <iU42ZXbSvzO_spkijiSKa-6yYpD3TcdIyV4bRpoELXY=.6d37541f-66f0-4ad9-9103-793221b5c810@github.com>

On Fri, 5 Sep 2025 06:16:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE

make/autoconf/flags-cflags.m4 line 963:

> 961:       AC_MSG_RESULT([$sve_supported])
> 962:       $2SVE_CFLAGS=""
> 963:       if test "x$enable_aarch64_sve" = "xyes"; then

`UTIL_ARG_ENABLE` will return `true`, not `yes`. Have you even tested this code?

make/autoconf/flags-cflags.m4 line 997:

> 995: [
> 996:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
> 997:       RESULT: enable_aarch64_sve,

We use upper-case letters for everything but variables that are local to a function. A name like `AARCH64_SVE_ENABLED` would be more in line with how we usually name these variables (even if, for historical reasons, we have not been consistent with this.)

In fact, `UTIL_ARG_ENABLE` will create `AARCH64_SVE_ENABLED` for you automatically if you do not set `RESULT:`, but for clarity this is still recommended.

make/autoconf/flags-cflags.m4 line 999:

> 997:       RESULT: enable_aarch64_sve,
> 998:       DESC: [Use SVE when compile libsleef])
> 999:   AC_SUBST(enable_aarch64_sve)

You don't need `AC_SUBST`. You are not exporting this to spec.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2332257596
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2332252805
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2332253539

From ihse at openjdk.org  Tue Sep  9 07:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 07:21:16 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <Oyb7ajBYNKtR3pnckFxstsIUmiFBum8EoG5EeMy53vc=.710ff2ba-0f5a-4b92-9d0d-f5237f9fd67d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
 <Oyb7ajBYNKtR3pnckFxstsIUmiFBum8EoG5EeMy53vc=.710ff2ba-0f5a-4b92-9d0d-f5237f9fd67d@github.com>
Message-ID: <C8-jmEnq6YVAi9ihkCfiqRSSmFTKMvd17EQQqIr5JZo=.d33880c6-0a87-42af-b041-579226f0669d@github.com>

On Sun, 7 Sep 2025 14:04:40 GMT, SendaoYan <syan at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 996:
>> 
>>> 994: AC_DEFUN([BPERF_SETUP_SVE],
>>> 995: [
>>> 996:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>> 
>> The idea with this macro is that you put the supported check and actions on enabled/disabled in the call and let it handle the logic. It shouldn't be moved to a separate macro. Also, macros defined in this file should have the `FLAGS` prefix, not `BPERF`.
>
> I also want to put the put the supported check and actions on enabled/disabled in the call previous. But I found that the configure will stuck at below command:
> 
> 
> ++ /usr/bin/autoconf -W all -I/home/yansendao/git/jdk-ysd/make/autoconf -
> 
> 
> The change like that:
> 
> 
> diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
> index 97e37cc923b..96ea730e80a 100644
> --- a/make/autoconf/flags-cflags.m4
> +++ b/make/autoconf/flags-cflags.m4
> @@ -940,6 +940,10 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
>    # ACLE and this flag are required to build the aarch64 SVE related functions in
>    # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
>    # that check.
> +  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
> +      RESULT: enable_aarch64_sve,
> +      DESC: [Use SVE when compile libsleef])
> +  AC_SUBST(enable_aarch64_sve)
>    if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
>      if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>        AC_LANG_PUSH(C)
> @@ -991,14 +995,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
>    AC_SUBST($2SVE_CFLAGS)
>  ])
> 
> -AC_DEFUN([BPERF_SETUP_SVE],
> -[
> -  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
> -      RESULT: enable_aarch64_sve,
> -      DESC: [Use SVE when compile libsleef])
> -  AC_SUBST(enable_aarch64_sve)
> -])
> -
>  AC_DEFUN_ONCE([FLAGS_SETUP_BRANCH_PROTECTION],
>  [
>    # Is branch protection available?
> 
> 
> I think I should find other solution later.

This is since `FLAGS_SETUP_CFLAGS_CPU_DEP` is called twice. UTIL_ARG_ENABLE should only be called once. So it is (unfortunately) correct that the call to UTIL_ARG_ENABLE cannot be close to where it is used, in this case. 

However, it seems excessive to call a separate function from the top-level configure.ac only for that. I believe you can just inline this into FLAGS_SETUP_FLAGS, or at the very least, call `FLAGS_SETUP_SVE` (as it should be called, if kept) from  FLAGS_SETUP_FLAGS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2332273569

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 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 ihse at openjdk.org  Tue Sep  9 08:13:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 08:13:06 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc [v2]
In-Reply-To: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
Message-ID: <qrTHaWZxwOxwkos98e7SB9NuTLalyL7fRQMjbx2g8_A=.68349f95-e6af-4962-a616-3b291387fa2d@github.com>

> According to https://github.com/openjdk/jdk/pull/26661#issuecomment-3162014034, we should not build gtest with `/EHsc`. 
> 
> I can honestly say I don't fully understand the consequences of this change, but at least it passes building and testing on Oracle CI. And it does seem to make sense that we build the gtest version of libjvm as close as possible to the real version. For libgtest I just thought it was prudent to keep the flags in sync with how we build libjvm. This might not be the correct decision.
> 
> I have not tested how or if this affects the ability for gtest to handle bugs or crashes in the JVM, nor do I really have any idea about any such consequences. This PR is opened more to start a discussion than with the intention of just integrating this.

Magnus Ihse Bursie 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 no-gtest-ehsc
 - 8365231: Don't build gtest with /EHsc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26721/files
  - new: https://git.openjdk.org/jdk/pull/26721/files/69ad27ec..f2127bb3

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

  Stats: 57704 lines in 1959 files changed: 33331 ins; 15569 del; 8804 mod
  Patch: https://git.openjdk.org/jdk/pull/26721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26721/head:pull/26721

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

From ihse at openjdk.org  Tue Sep  9 08:13:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 08:13:12 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc [v2]
In-Reply-To: <LNFzWcZpbSi-5zJoFW1NXx22oJIe-D0S_iLMCJnvqjs=.b0264468-8edb-41f6-bc59-d3836497b773@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <LNFzWcZpbSi-5zJoFW1NXx22oJIe-D0S_iLMCJnvqjs=.b0264468-8edb-41f6-bc59-d3836497b773@github.com>
Message-ID: <-GRCnnah3I7IDPMhKx3b4kGYpq1bRSxuKcSLl_AkqGo=.4a74927a-375c-4d72-8844-e7d92de196e9@github.com>

On Thu, 14 Aug 2025 13:31:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie 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 no-gtest-ehsc
>>  - 8365231: Don't build gtest with /EHsc
>
> make/hotspot/lib/CompileGtest.gmk line 112:
> 
>> 110:     DISABLED_WARNINGS_clang_test_g1ServiceThread.cpp := delete-abstract-non-virtual-dtor, \
>> 111:     DISABLED_WARNINGS_clang_test_logDecorations.cpp := missing-field-initializers, \
>> 112:     DISABLED_WARNINGS_microsoft := $(DISABLED_WARNINGS_microsoft) 4530, \
> 
> How widespread are these warnings? I expect such a warning from jfr/test_networkUtilization.cpp,
> but not anywhere else. Could the disable of this warning be narrowed accordingly?

I checked. It is for all `test_*.cpp` files, due to gtest include files. So we need to to this broad spectrum disable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26721#discussion_r2332407984

From ihse at openjdk.org  Tue Sep  9 08:23:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 08:23:57 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc [v3]
In-Reply-To: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
Message-ID: <HHOJehM6HMpGER63CzaDulXwF2NjBPGF3vtn6ahbo2I=.5a9f83ab-6d20-4e48-b495-8ac69a92451a@github.com>

> According to https://github.com/openjdk/jdk/pull/26661#issuecomment-3162014034, we should not build gtest with `/EHsc`. 
> 
> I can honestly say I don't fully understand the consequences of this change, but at least it passes building and testing on Oracle CI. And it does seem to make sense that we build the gtest version of libjvm as close as possible to the real version. For libgtest I just thought it was prudent to keep the flags in sync with how we build libjvm. This might not be the correct decision.
> 
> I have not tested how or if this affects the ability for gtest to handle bugs or crashes in the JVM, nor do I really have any idea about any such consequences. This PR is opened more to start a discussion than with the intention of just integrating this.

Magnus Ihse Bursie 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 'master' into no-gtest-ehsc
 - Merge branch 'master' into no-gtest-ehsc
 - 8365231: Don't build gtest with /EHsc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26721/files
  - new: https://git.openjdk.org/jdk/pull/26721/files/f2127bb3..3c2f340c

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

  Stats: 228 lines in 12 files changed: 43 ins; 163 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/26721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26721/head:pull/26721

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

From ihse at openjdk.org  Tue Sep  9 08:26:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 08:26:48 GMT
Subject: RFR: 8246325: Add DRYRUN facility to SetupExecute
Message-ID: <UR5iceYz8siAu3wOu2XT5CQHyl-0k5j58bnArPHhCAQ=.ff1aada1-e954-4e57-a143-5b4ce8a82173@github.com>

With `DRYRUN := true`, the actual command line will not be executed, but all other steps are done, to facilitate debugging. 

This PR has effects on some closed Oracle code, hence the changes in the mac bundle path logic.

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

Commit messages:
 - Add tests for DRYRUN
 - 8246325: Add DRYRUN facility to SetupExecute

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

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

From ihse at openjdk.org  Tue Sep  9 11:01:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 11:01:16 GMT
Subject: Integrated: 8365231: Don't build gtest with /EHsc
In-Reply-To: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
Message-ID: <MYCJDx1iOBg-SN8zUZTD8Xz_hJqEkjtmhat0R0PiqIY=.33844d7a-e021-40a0-8136-c7b24212d7b6@github.com>

On Mon, 11 Aug 2025 09:55:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to https://github.com/openjdk/jdk/pull/26661#issuecomment-3162014034, we should not build gtest with `/EHsc`. 
> 
> I can honestly say I don't fully understand the consequences of this change, but at least it passes building and testing on Oracle CI. And it does seem to make sense that we build the gtest version of libjvm as close as possible to the real version. For libgtest I just thought it was prudent to keep the flags in sync with how we build libjvm. This might not be the correct decision.
> 
> I have not tested how or if this affects the ability for gtest to handle bugs or crashes in the JVM, nor do I really have any idea about any such consequences. This PR is opened more to start a discussion than with the intention of just integrating this.

This pull request has now been integrated.

Changeset: a25dde62
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a25dde6279c100dcff266d19b263e764f5da244e
Stats:     4 lines in 1 file changed: 1 ins; 2 del; 1 mod

8365231: Don't build gtest with /EHsc

Reviewed-by: kbarrett, stuefe

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

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

From ihse at openjdk.org  Tue Sep  9 11:35:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 11:35:42 GMT
Subject: RFR: 8344030: Improved handling of TOOLCHAIN_PATH
Message-ID: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>

This bug report was triggered by the discussion in https://github.com/openjdk/jdk/pull/21999.

In TOOLCHAIN_PRE_DETECTION, we prepend $TOOLCHAIN_PATH to the actual PATH, and then restore this in TOOLCHAIN_POST_DETECTION. This is likely a remnant of older times, before we started using our own UTIL_LOOKUP* functions.

Instead, we should update UTIL_LOOKUP_TOOLCHAIN_PROGS to use $TOOLCHAIN_PATH:$PATH as 3rd variable to UTIL_LOOKUP_PROGS (if it is not given).

The risk we need to be aware of is if some tool we're running assume that the TOOLCHAIN_PATH is properly included on the PATH, e.g. because it tries to execute a helper command in turn. This could specifically be a problem for Visual Studio, and we need to double-check that removing TOOLCHAIN_PATH from the PATH does not break anything. (In fact, I believe we already append TOOLCHAIN_PATH to the PATH specifically for Windows already, so this could very well be done twice...)

With these changes in place, the hack introduced by [JDK-8343883](https://bugs.openjdk.org/browse/JDK-8343883) can be changed to a simple call to UTIL_LOOKUP_TOOLCHAIN_PROGS.

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

Commit messages:
 - Merge branch 'master' into fix-toolchain-path
 - 8344030: Improved handling of TOOLCHAIN_PATH

Changes: https://git.openjdk.org/jdk/pull/24525/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24525&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344030
  Stats: 69 lines in 6 files changed: 6 ins; 51 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24525/head:pull/24525

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

From ihse at openjdk.org  Tue Sep  9 11:38:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 11:38:12 GMT
Subject: RFR: 8344030: Improved handling of TOOLCHAIN_PATH
In-Reply-To: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
References: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
Message-ID: <L_X3mSEM-xoaWntJKhNYSzwaWGrA6y52iGwXEPTQC14=.03941cf7-3f52-4aeb-b0e1-529c38c6181a@github.com>

On Tue, 8 Apr 2025 19:50:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This bug report was triggered by the discussion in https://github.com/openjdk/jdk/pull/21999.
> 
> In TOOLCHAIN_PRE_DETECTION, we prepend $TOOLCHAIN_PATH to the actual PATH, and then restore this in TOOLCHAIN_POST_DETECTION. This is likely a remnant of older times, before we started using our own UTIL_LOOKUP* functions.
> 
> Instead, we should update UTIL_LOOKUP_TOOLCHAIN_PROGS to use $TOOLCHAIN_PATH:$PATH as 3rd variable to UTIL_LOOKUP_PROGS (if it is not given).
> 
> The risk we need to be aware of is if some tool we're running assume that the TOOLCHAIN_PATH is properly included on the PATH, e.g. because it tries to execute a helper command in turn. This could specifically be a problem for Visual Studio, and we need to double-check that removing TOOLCHAIN_PATH from the PATH does not break anything. (In fact, I believe we already append TOOLCHAIN_PATH to the PATH specifically for Windows already, so this could very well be done twice...)
> 
> With these changes in place, the hack introduced by [JDK-8343883](https://bugs.openjdk.org/browse/JDK-8343883) can be changed to a simple call to UTIL_LOOKUP_TOOLCHAIN_PROGS.

This has passed Oracle internal CI testing for "builds-infra" tier 1-5.

I have tried doing some manual adhoc testing, and it seems to work fine. The risk is that there is some odd environment out there where stuff might go wrong. I believe there should be no technical difference in how configure detects tools before and after this PR (with one exception: now for `make` it will look in TOOLSDIR before PATH. I think this is correct and what we should have done from the beginning, but it is a change). But it is impossible to find out about all such cases before integration. 

If someone runs into problems and come looking here: The short-term workaround is that any tool can be overridden with a complete path on the command line, so if e.g. `make` is incorrectly detected, you can run `bash configure MAKE=<path to your make>`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24525#issuecomment-3270283531

From ihse at openjdk.org  Tue Sep  9 11:46:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 11:46:21 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v5]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <eup90_gYXUP9h0YZZ9_RPdb8tzG32wldQ4KsXPNaluU=.5699ee4d-1fb9-4195-aff9-95a6f808593b@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into static-relaunchers
 - Use ReadFile instead
 - Merge branch 'master' into static-relaunchers
 - Remove problemlisting
 - Merge branch 'master' into static-relaunchers
 - Improve windows runtime lib copying
 - Fix linux launcher to allow relaunching
 - Copy Windows runtime libs
 - Merge branch 'master' into static-relaunchers
 - Merge branch 'master' into static-relaunchers
 - ... and 7 more: https://git.openjdk.org/jdk/compare/06326176...41b5030b

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

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=04
  Stats: 817 lines in 14 files changed: 628 ins; 143 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380

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

From ihse at openjdk.org  Tue Sep  9 13:15:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 13:15:57 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24380/files
  - new: https://git.openjdk.org/jdk/pull/24380/files/41b5030b..0ba27090

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

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

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

From ihse at openjdk.org  Tue Sep  9 13:15:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 13:15:58 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
 <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>
 <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>
 <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>
 <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>
 <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>
Message-ID: <9ViQUUyQ396N0y0_EChd4GDw1Ns9CPoPJLfQb2Zax5E=.5c72c24a-761f-42b3-88b2-8114e3470eef@github.com>

On Mon, 11 Aug 2025 17:20:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. 
>> 
>> Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant.
>> 
>> Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.)
>
> I'm not sure what you mean here. I described a solution that keeps it in LauncherCommon without creating races.

@erikj79 I've finally gotten around to fixing this. Looks ok?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2333542410

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 ihse at openjdk.org  Tue Sep  9 14:39:28 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 9 Sep 2025 14:39:28 GMT
Subject: RFR: 8367259: Clean up make/scripts and bin directory
Message-ID: <wds-iGkjcraFgDX9YxZwW2GhGbNN--ZasZVh0jtOq8U=.704b6d9b-87ae-4c4c-8968-a07244c64bef@github.com>

Over time, cruft have accumulated in terms of scripts that are no longer relevant. These should be removed. Also, scripts that are not used as part of the build process, but run by JDK developers from time to time, should reside in `bin` instead of `make/scripts`.

I have also updated `generate-symbol-data.sh` and `update_pch.sh` so they work regardless of current dir.

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

Commit messages:
 - 8367259: Clean up make/scripts and bin directory

Changes: https://git.openjdk.org/jdk/pull/27172/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367259
  Stats: 657 lines in 11 files changed: 113 ins; 540 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27172/head:pull/27172

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

From erikj at openjdk.org  Tue Sep  9 16:59:49 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 Sep 2025 16:59:49 GMT
Subject: RFR: 8344030: Improved handling of TOOLCHAIN_PATH
In-Reply-To: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
References: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
Message-ID: <LMu9jDyeSTBeiAtsiSKtHHbXywq24oFVusqYUBVVtII=.275e57ad-4243-4291-86b1-6b8b1186943a@github.com>

On Tue, 8 Apr 2025 19:50:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This bug report was triggered by the discussion in https://github.com/openjdk/jdk/pull/21999.
> 
> In TOOLCHAIN_PRE_DETECTION, we prepend $TOOLCHAIN_PATH to the actual PATH, and then restore this in TOOLCHAIN_POST_DETECTION. This is likely a remnant of older times, before we started using our own UTIL_LOOKUP* functions.
> 
> Instead, we should update UTIL_LOOKUP_TOOLCHAIN_PROGS to use $TOOLCHAIN_PATH:$PATH as 3rd variable to UTIL_LOOKUP_PROGS (if it is not given).
> 
> The risk we need to be aware of is if some tool we're running assume that the TOOLCHAIN_PATH is properly included on the PATH, e.g. because it tries to execute a helper command in turn. This could specifically be a problem for Visual Studio, and we need to double-check that removing TOOLCHAIN_PATH from the PATH does not break anything. (In fact, I believe we already append TOOLCHAIN_PATH to the PATH specifically for Windows already, so this could very well be done twice...)
> 
> With these changes in place, the hack introduced by [JDK-8343883](https://bugs.openjdk.org/browse/JDK-8343883) can be changed to a simple call to UTIL_LOOKUP_TOOLCHAIN_PROGS.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24525#pullrequestreview-3202485163

From erikj at openjdk.org  Tue Sep  9 17:18:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 Sep 2025 17:18:46 GMT
Subject: RFR: 8367259: Clean up make/scripts and bin directory
In-Reply-To: <wds-iGkjcraFgDX9YxZwW2GhGbNN--ZasZVh0jtOq8U=.704b6d9b-87ae-4c4c-8968-a07244c64bef@github.com>
References: <wds-iGkjcraFgDX9YxZwW2GhGbNN--ZasZVh0jtOq8U=.704b6d9b-87ae-4c4c-8968-a07244c64bef@github.com>
Message-ID: <MLI6WA8nLRyH_PJhkP5cm7eYoUTFv2EtcLVEWPrxOc4=.5de78372-f8a3-4807-b27f-56b87e3d01cb@github.com>

On Tue, 9 Sep 2025 13:55:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, cruft have accumulated in terms of scripts that are no longer relevant. These should be removed. Also, scripts that are not used as part of the build process, but run by JDK developers from time to time, should reside in `bin` instead of `make/scripts`.
> 
> I have also updated `generate-symbol-data.sh` and `update_pch.sh` so they work regardless of current dir.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27172#pullrequestreview-3202554210

From erikj at openjdk.org  Tue Sep  9 17:15:50 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 Sep 2025 17:15:50 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
Message-ID: <g4XYSYiCjHsrvIajcivyGlOIRpjaK-pKykZqsK_J24E=.63a0f01f-b783-4972-92f4-4ebab564cbfc@github.com>

On Tue, 9 Sep 2025 13:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review

Build changes look good thanks!

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3202542309

From erikj at openjdk.org  Tue Sep  9 19:34:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 Sep 2025 19:34:39 GMT
Subject: RFR: 8246325: Add DRYRUN facility to SetupExecute
In-Reply-To: <UR5iceYz8siAu3wOu2XT5CQHyl-0k5j58bnArPHhCAQ=.ff1aada1-e954-4e57-a143-5b4ce8a82173@github.com>
References: <UR5iceYz8siAu3wOu2XT5CQHyl-0k5j58bnArPHhCAQ=.ff1aada1-e954-4e57-a143-5b4ce8a82173@github.com>
Message-ID: <142E3zGOZgWJrPeXEwhsXz7X5wwLpXcY6_rNkQQJCgk=.3db40318-704b-4fb7-86c3-6d2cef796e33@github.com>

On Fri, 5 Sep 2025 15:44:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With `DRYRUN := true`, the actual command line will not be executed, but all other steps are done, to facilitate debugging. 
> 
> This PR has effects on some closed Oracle code, hence the changes in the mac bundle path logic.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27121#pullrequestreview-3202993327

From syan at openjdk.org  Wed Sep 10 02:23:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 02:23:12 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <iU42ZXbSvzO_spkijiSKa-6yYpD3TcdIyV4bRpoELXY=.6d37541f-66f0-4ad9-9103-793221b5c810@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <iU42ZXbSvzO_spkijiSKa-6yYpD3TcdIyV4bRpoELXY=.6d37541f-66f0-4ad9-9103-793221b5c810@github.com>
Message-ID: <geS-p_I_By06Qkte9PBf2J2JAKgc-ECOaupnI9moQDk=.b95e75b0-275e-4407-ba71-1953dbc73bcd@github.com>

On Tue, 9 Sep 2025 07:11:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE
>
> make/autoconf/flags-cflags.m4 line 963:
> 
>> 961:       AC_MSG_RESULT([$sve_supported])
>> 962:       $2SVE_CFLAGS=""
>> 963:       if test "x$enable_aarch64_sve" = "xyes"; then
> 
> `UTIL_ARG_ENABLE` will return `true`, not `yes`. Have you even tested this code?

I did the test before. I was also confused that the `enable_aarch64_sve` sometimes return `yes`/`no`, sometimes return `true`/`false`, it seems depends the code implementations.

The log snippet after run bash configure.


> grep "enable_aarch64_sve=" build/linux-aarch64-server-release/configure.log -n
1117:+++ eval 'enable_aarch64_sve=$ac_optarg'
1118:++++ enable_aarch64_sve=yes
20015:+++ enable_aarch64_sve=true


[configure.log](https://github.com/user-attachments/files/22246010/configure.log)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2335313423

From syan at openjdk.org  Wed Sep 10 08:40:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 08:40:20 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v7]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <OD6GHQAQC5URlx00DQUJOPnZjRzsoHHe9Dl16Zy6osc=.59ab3c3f-12e7-48ff-8c9c-5a504f5ebc84@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Inline UTIL_ARG_ENABLE aarch64-sve to FLAGS_SETUP_FLAGS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/21c7576b..612fbe5f

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

  Stats: 21 lines in 3 files changed: 4 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27073/head:pull/27073

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

From syan at openjdk.org  Wed Sep 10 08:59:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 08:59:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <C8-jmEnq6YVAi9ihkCfiqRSSmFTKMvd17EQQqIr5JZo=.d33880c6-0a87-42af-b041-579226f0669d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
 <Oyb7ajBYNKtR3pnckFxstsIUmiFBum8EoG5EeMy53vc=.710ff2ba-0f5a-4b92-9d0d-f5237f9fd67d@github.com>
 <C8-jmEnq6YVAi9ihkCfiqRSSmFTKMvd17EQQqIr5JZo=.d33880c6-0a87-42af-b041-579226f0669d@github.com>
Message-ID: <ltIcsuM8fkTzzIw3-4dRTPLq-bXKWqTgTOhayuhjaAE=.a8de5bfd-251a-4b31-8d7f-460711a144dd@github.com>

On Tue, 9 Sep 2025 07:18:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I also want to put the put the supported check and actions on enabled/disabled in the call previous. But I found that the configure will stuck at below command:
>> 
>> 
>> ++ /usr/bin/autoconf -W all -I/home/yansendao/git/jdk-ysd/make/autoconf -
>> 
>> 
>> The change like that:
>> 
>> 
>> diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
>> index 97e37cc923b..96ea730e80a 100644
>> --- a/make/autoconf/flags-cflags.m4
>> +++ b/make/autoconf/flags-cflags.m4
>> @@ -940,6 +940,10 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
>>    # ACLE and this flag are required to build the aarch64 SVE related functions in
>>    # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
>>    # that check.
>> +  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>> +      RESULT: enable_aarch64_sve,
>> +      DESC: [Use SVE when compile libsleef])
>> +  AC_SUBST(enable_aarch64_sve)
>>    if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
>>      if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>>        AC_LANG_PUSH(C)
>> @@ -991,14 +995,6 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
>>    AC_SUBST($2SVE_CFLAGS)
>>  ])
>> 
>> -AC_DEFUN([BPERF_SETUP_SVE],
>> -[
>> -  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>> -      RESULT: enable_aarch64_sve,
>> -      DESC: [Use SVE when compile libsleef])
>> -  AC_SUBST(enable_aarch64_sve)
>> -])
>> -
>>  AC_DEFUN_ONCE([FLAGS_SETUP_BRANCH_PROTECTION],
>>  [
>>    # Is branch protection available?
>> 
>> 
>> I think I should find other solution later.
>
> This is since `FLAGS_SETUP_CFLAGS_CPU_DEP` is called twice. UTIL_ARG_ENABLE should only be called once. So it is (unfortunately) correct that the call to UTIL_ARG_ENABLE cannot be close to where it is used, in this case. 
> 
> However, it seems excessive to call a separate function from the top-level configure.ac only for that. I believe you can just inline this into FLAGS_SETUP_FLAGS, or at the very least, call `FLAGS_SETUP_SVE` (as it should be called, if kept) from  FLAGS_SETUP_FLAGS.

Hi @magicus Thanks your suggesions. I choose to inline the `UTIL_ARG_ENABLE aarch64-sve` to FLAGS_SETUP_FLAGS, because call `FLAGS_SETUP_SVE` from `FLAGS_SETUP_FLAGS` seems do not work nornally. This solution results in a difference in code style before and after.

If I choose to call FLAGS_SETUP_SVE in FLAGS_SETUP_FLAGS macro solution, if call FLAGS_SETUP_SVE before FLAGS_SETUP_CFLAGS, `bash configure` will report 'unrecognized options: --enable-aarch64-sve''; if call FLAGS_SETUP_SVE after FLAGS_SETUP_CFLAGS, the value of AARCH64_SVE_ENABLED is empty when FLAGS_SETUP_CFLAGS_CPU_DEP read it, seems FLAGS_SETUP_CFLAGS_CPU_DEP been called before FLAGS_SETUP_SVE been called.

Sorry I do not familar with makefiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336060870

From syan at openjdk.org  Wed Sep 10 09:22:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 09:22:45 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v8]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <xyysKPrG_cPVr_TbhFLlSWQEYwmmxtP6-kQNtZW-uZU=.dab2689a-8026-4418-84c4-591f7b25a346@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Change CC and CFLAGS to the correct compiler and flags setup when call AC_COMPILER_IFELSE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/612fbe5f..8e2b399b

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

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

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

From syan at openjdk.org  Wed Sep 10 09:22:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 09:22:54 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <I3c5whe2bvIz0zCU0qKWFtBSo-QYnp6yiBZ6Rkc4yJU=.a9c659a0-82db-4be7-b260-ae6edccb7b92@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I3c5whe2bvIz0zCU0qKWFtBSo-QYnp6yiBZ6Rkc4yJU=.a9c659a0-82db-4be7-b260-ae6edccb7b92@github.com>
Message-ID: <rTxyojQI0X5-2N0LxywSU3_SoxdZfbI4NboRTC0rJiM=.93dfe0e1-8191-484a-ab22-2b5e8fdc49d8@github.com>

On Tue, 9 Sep 2025 07:06:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE
>
> make/autoconf/flags-cflags.m4 line 994:
> 
>> 992: ])
>> 993: 
>> 994: AC_DEFUN([BPERF_SETUP_SVE],
> 
> The `BPERF_` prefix says that this function belongs to build-performance.m4.

Fixed.

> make/autoconf/flags-cflags.m4 line 997:
> 
>> 995: [
>> 996:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>> 997:       RESULT: enable_aarch64_sve,
> 
> We use upper-case letters for everything but variables that are local to a function. A name like `AARCH64_SVE_ENABLED` would be more in line with how we usually name these variables (even if, for historical reasons, we have not been consistent with this.)
> 
> In fact, `UTIL_ARG_ENABLE` will create `AARCH64_SVE_ENABLED` for you automatically if you do not set `RESULT:`, but for clarity this is still recommended.

Thanks. Fixed.

> make/autoconf/flags-cflags.m4 line 999:
> 
>> 997:       RESULT: enable_aarch64_sve,
>> 998:       DESC: [Use SVE when compile libsleef])
>> 999:   AC_SUBST(enable_aarch64_sve)
> 
> You don't need `AC_SUBST`. You are not exporting this to spec.gmk.

Thanks for the explanation. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336119267
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336120905
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336129218

From syan at openjdk.org  Wed Sep 10 09:22:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 09:22:49 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
Message-ID: <BnNtVNqicrpZUoCriM8qaNL06PHfHrks01PXegOd0lo=.3854e7a2-010f-4e41-9633-85ef50c774fe@github.com>

On Fri, 5 Sep 2025 12:58:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE
>
> make/autoconf/flags-cflags.m4 line 950:
> 
>> 948:       # check the compiler and binutils support sve or not
>> 949:       AC_MSG_CHECKING([if Arm SVE ACLE is supported])
>> 950:       AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
> 
> Now that I started looking closer at this, I realize that we are inside a macro that gets called for both the BUILD and TARGET compiler (note the $2 prefix on several variables). For a call to `AC_COMPILER_IFELSE` to work correctly in that context, you need to temporarily change `CC` and `CFLAGS` to the correct compiler and flags setup. See the definition of `FLAGS_C_COMPILER_CHECK_ARGUMENTS` in flags.m4 to see how that is done.

Thanks for the review and suggestion. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336117442

From ayang at openjdk.org  Wed Sep 10 09:30:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 10 Sep 2025 09:30:52 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: <bVSuLGjkXSXUlq7Q4lQuwSmtgqGJJoQM0Nf9tIDkjFg=.ca620bbc-c724-43c7-b029-3fceb6ea9908@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.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3205293803

From syan at openjdk.org  Wed Sep 10 09:38:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 09:38:59 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Include the prefix argument when calling FLAGS_COMPILER_CHECK_ARGUMENTS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/8e2b399b..82cf06c1

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

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

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

From ihse at openjdk.org  Wed Sep 10 10:01:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 10:01:03 GMT
Subject: Integrated: 8367259: Clean up make/scripts and bin directory
In-Reply-To: <wds-iGkjcraFgDX9YxZwW2GhGbNN--ZasZVh0jtOq8U=.704b6d9b-87ae-4c4c-8968-a07244c64bef@github.com>
References: <wds-iGkjcraFgDX9YxZwW2GhGbNN--ZasZVh0jtOq8U=.704b6d9b-87ae-4c4c-8968-a07244c64bef@github.com>
Message-ID: <Ocs6mLgjBoKSiTR-9nQ_wLkQ_hV_nsRMTpBG81pj7Uc=.c8ad30ec-8dfc-4f42-a80f-fcd2df6094ae@github.com>

On Tue, 9 Sep 2025 13:55:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, cruft have accumulated in terms of scripts that are no longer relevant. These should be removed. Also, scripts that are not used as part of the build process, but run by JDK developers from time to time, should reside in `bin` instead of `make/scripts`.
> 
> I have also updated `generate-symbol-data.sh` and `update_pch.sh` so they work regardless of current dir.

This pull request has now been integrated.

Changeset: 5c9f60dc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c9f60dc5a6e64be55819469bbf10948803d0fd5
Stats:     657 lines in 11 files changed: 113 ins; 540 del; 4 mod

8367259: Clean up make/scripts and bin directory

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Wed Sep 10 10:03:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 10:03:02 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <geS-p_I_By06Qkte9PBf2J2JAKgc-ECOaupnI9moQDk=.b95e75b0-275e-4407-ba71-1953dbc73bcd@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <iU42ZXbSvzO_spkijiSKa-6yYpD3TcdIyV4bRpoELXY=.6d37541f-66f0-4ad9-9103-793221b5c810@github.com>
 <geS-p_I_By06Qkte9PBf2J2JAKgc-ECOaupnI9moQDk=.b95e75b0-275e-4407-ba71-1953dbc73bcd@github.com>
Message-ID: <avnLJeHque-XISj9HqoqMeSQNvlgsnOmcBQ-fY_xzNQ=.a2144edf-5f59-47e1-ba8f-d69e2c65e3db@github.com>

On Wed, 10 Sep 2025 02:20:03 GMT, SendaoYan <syan at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 963:
>> 
>>> 961:       AC_MSG_RESULT([$sve_supported])
>>> 962:       $2SVE_CFLAGS=""
>>> 963:       if test "x$enable_aarch64_sve" = "xyes"; then
>> 
>> `UTIL_ARG_ENABLE` will return `true`, not `yes`. Have you even tested this code?
>
> I did the test before. I was also confused that the `enable_aarch64_sve` sometimes return `yes`/`no`, sometimes return `true`/`false`, it seems depends the code implementations.
> 
> The log snippet after run bash configure.
> 
> 
>> grep "enable_aarch64_sve=" build/linux-aarch64-server-release/configure.log -n
> 1117:+++ eval 'enable_aarch64_sve=$ac_optarg'
> 1118:++++ enable_aarch64_sve=yes
> 20015:+++ enable_aarch64_sve=true
> 
> 
> [configure.log](https://github.com/user-attachments/files/22246010/configure.log)

So if you used the AC_ version, it will set enable_aarch64_sve with yes/no, but then you switched to the UTIL_ version, but you kept the same name as argument. That just causes a mess. I guess the UTIL_ version, which calls the AC_function at its core, will override the value. But just don't use that name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336237203

From ihse at openjdk.org  Wed Sep 10 10:03:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 10:03:11 GMT
Subject: Integrated: 8344030: Improved handling of TOOLCHAIN_PATH
In-Reply-To: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
References: <2aEVHLE3NYGqJabEKwj1VKsXyJvF8WuAzQrxzZEozHY=.d9484024-d784-47f5-81c7-a173844b1a63@github.com>
Message-ID: <7Xt483pDRziqYWPUlu4wY8nFaaTXlXhItlb32jaRY-c=.dc4db96f-2ab6-4ce6-9372-b339b90c7a72@github.com>

On Tue, 8 Apr 2025 19:50:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This bug report was triggered by the discussion in https://github.com/openjdk/jdk/pull/21999.
> 
> In TOOLCHAIN_PRE_DETECTION, we prepend $TOOLCHAIN_PATH to the actual PATH, and then restore this in TOOLCHAIN_POST_DETECTION. This is likely a remnant of older times, before we started using our own UTIL_LOOKUP* functions.
> 
> Instead, we should update UTIL_LOOKUP_TOOLCHAIN_PROGS to use $TOOLCHAIN_PATH:$PATH as 3rd variable to UTIL_LOOKUP_PROGS (if it is not given).
> 
> The risk we need to be aware of is if some tool we're running assume that the TOOLCHAIN_PATH is properly included on the PATH, e.g. because it tries to execute a helper command in turn. This could specifically be a problem for Visual Studio, and we need to double-check that removing TOOLCHAIN_PATH from the PATH does not break anything. (In fact, I believe we already append TOOLCHAIN_PATH to the PATH specifically for Windows already, so this could very well be done twice...)
> 
> With these changes in place, the hack introduced by [JDK-8343883](https://bugs.openjdk.org/browse/JDK-8343883) can be changed to a simple call to UTIL_LOOKUP_TOOLCHAIN_PROGS.

This pull request has now been integrated.

Changeset: 33244c82
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33244c82445994131a9168451275216916ce635c
Stats:     69 lines in 6 files changed: 6 ins; 51 del; 12 mod

8344030: Improved handling of TOOLCHAIN_PATH

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Wed Sep 10 10:30:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 10:30:39 GMT
Subject: Integrated: 8246325: Add DRYRUN facility to SetupExecute
In-Reply-To: <UR5iceYz8siAu3wOu2XT5CQHyl-0k5j58bnArPHhCAQ=.ff1aada1-e954-4e57-a143-5b4ce8a82173@github.com>
References: <UR5iceYz8siAu3wOu2XT5CQHyl-0k5j58bnArPHhCAQ=.ff1aada1-e954-4e57-a143-5b4ce8a82173@github.com>
Message-ID: <LVf9DbWCpgxiR2sRvyT0sFZOC3JehJyL5CKr0BMJfdc=.b231066a-4d9f-4cbd-99d6-72d8d4bea71b@github.com>

On Fri, 5 Sep 2025 15:44:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With `DRYRUN := true`, the actual command line will not be executed, but all other steps are done, to facilitate debugging. 
> 
> This PR has effects on some closed Oracle code, hence the changes in the mac bundle path logic.

This pull request has now been integrated.

Changeset: edae355e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edae355e95f23294eda092dbedcb7f6cf165b0f8
Stats:     46 lines in 4 files changed: 34 ins; 0 del; 12 mod

8246325: Add DRYRUN facility to SetupExecute

Reviewed-by: erikj

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

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

From syan at openjdk.org  Wed Sep 10 12:08:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 12:08:36 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v6]
In-Reply-To: <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <CXSSMCkb5fknjRo3-o8CBcEMXJfkuBoUUrMSbK_Jhbk=.23c5b3c1-78c7-4995-b62e-f9540a1e9ffa@github.com>
 <I9QIHlbbeYyfsWv8dRIYFc7bUI4iT8a0nLGlUOcRp3w=.1fe445ad-6f16-4f03-94f9-b5fcc859260d@github.com>
Message-ID: <coZ_llISq-_XvT3xU0hzyFpKvWOcGm7C9MxRV8Zsg-A=.fb9d80ac-1834-43a9-977a-d65cfd290a6f@github.com>

On Fri, 5 Sep 2025 13:00:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UTIL_ARG_ENABLE instead of AC_ARG_ENABLE
>
> make/autoconf/flags-cflags.m4 line 981:
> 
>> 979:       if test "x$$2SVE_CFLAGS" != "x" && test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
>> 980:         INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
>> 981:         FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],
> 
> When calling `FLAGS_COMPILER_CHECK_ARGUMENTS` you from this context, you need to include the `PREFIX` argument. See examples further up in this file.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2336537007

From ihse at openjdk.org  Wed Sep 10 12:31:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 12:31:20 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
Message-ID: <SBqjB2IdVsSfLxZPHACn-WpL7SjAA3RUfVhfUz2MNcs=.de69ae1e-d2e5-4311-b685-80937e6fcc3e@github.com>

On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
> 
> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.

@AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3274738832

From syan at openjdk.org  Wed Sep 10 13:13:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 13:13:15 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
Message-ID: <z_9f25y5_JSH_msAj6sbgk0v_QQ62gpCaLv8Z09zeMI=.900bb69b-7bcb-40c4-b2bd-9befd4ebadd6@github.com>

On Wed, 10 Sep 2025 09:38:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include the prefix argument when calling FLAGS_COMPILER_CHECK_ARGUMENTS

GHA job [linux-cross-compile / build (aarch64)](https://github.com/sendaoYan/jdk-ysd/actions/runs/17609624612/job/50028351829#logs) fails:


configure:178281: /usr/bin/cc -c  -march=armv8-a+sve -Werror -ffp-contract=off --sysroot=/home/runner/work/jdk-ysd/jdk-ysd/sysroot conftest.c >&5
cc1: error: bad value (?armv8-a+sve?) for ?-march=? switch
cc1: note: valid arguments to ?-march=? switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 native


/usr/bin/cc is native compiler.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3274916747

From ihse at openjdk.org  Wed Sep 10 13:16:30 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 13:16:30 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: <SqzOh6qVJxjyanbiFIsqZXHeTdFV-bBBNQqexGc_Qgk=.f09da42e-24a2-4238-9572-ea704c06acd9@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 ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3206106586

From erikj at openjdk.org  Wed Sep 10 14:04:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Sep 2025 14:04:56 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
Message-ID: <U321nmEqwxhuAIxq1E-cwcZVLhN9ivtrj3TEnyJWoi0=.de3dcbcf-3314-4f8f-b30c-0f6e6d0ec8e4@github.com>

On Wed, 10 Sep 2025 09:38:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include the prefix argument when calling FLAGS_COMPILER_CHECK_ARGUMENTS

One could also argue that the SVE CFLAGS aren't ever relevant to the build compiler and should be moved out of `FLAGS_SETUP_CFLAGS_CPU_DEP`, and only be performed for the target compiler, which would make the whole thing a lot simpler.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3275121611

From erikj at openjdk.org  Wed Sep 10 14:04:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Sep 2025 14:04:54 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <z_9f25y5_JSH_msAj6sbgk0v_QQ62gpCaLv8Z09zeMI=.900bb69b-7bcb-40c4-b2bd-9befd4ebadd6@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
 <z_9f25y5_JSH_msAj6sbgk0v_QQ62gpCaLv8Z09zeMI=.900bb69b-7bcb-40c4-b2bd-9befd4ebadd6@github.com>
Message-ID: <Z27IokUPzs9V9rpQ6725y_eZkXU07OgI-D6ukEEIZrI=.2befaa25-5c11-4fbe-996a-a480334d7242@github.com>

On Wed, 10 Sep 2025 13:10:07 GMT, SendaoYan <syan at openjdk.org> wrote:

> GHA job [linux-cross-compile / build (aarch64)](https://github.com/sendaoYan/jdk-ysd/actions/runs/17609624612/job/50028351829#logs) fails:
> 
> ```
> configure:178281: /usr/bin/cc -c  -march=armv8-a+sve -Werror -ffp-contract=off --sysroot=/home/runner/work/jdk-ysd/jdk-ysd/sysroot conftest.c >&5
> cc1: error: bad value (?armv8-a+sve?) for ?-march=? switch
> cc1: note: valid arguments to ?-march=? switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 native
> ```
> 
> /usr/bin/cc is linux-x64 native compiler, it should not receive linux-aarch64 gcc parameter `-march=armv8-a+sve`

This happens because the conditional for when to perform the check isn't correct. It's checking if `OPENJDK_TARGET_CPU` is aarch64, but that's the global target for the whole configuration. It should be checking if the current compiler target is aarch64. Before calling `FLAGS_SETUP_CFLAGS_CPU_DEP`, variables for this are setup. In this case you should be using `FLAGS_CPU` and `FLAGS_OS` instead of `OPENJDK_TARGET_CPU` and `OPENJDK_TARGET_OS`.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3275110912

From syan at openjdk.org  Wed Sep 10 14:30:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 14:30:20 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v10]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <raivjXzZZIs0hqK7uSJ8fdh9lJM4RiSicG8rqvrqfA4=.631cb0a3-50a3-4778-b92c-5b9428e6cbeb@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Use FLAGS_CPU and FLAGS_OS instead of OPENJDK_TARGET_CPU and OPENJDK_TARGET_OS to make cross-compile works normally

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/82cf06c1..1171cfa5

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

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

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

From ihse at openjdk.org  Wed Sep 10 14:30:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 10 Sep 2025 14:30:22 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
Message-ID: <TM5hYRnNh0zjjxf0HyCugB-gNR7t5SoBwQoDINK6spc=.051fb25b-0eec-4105-af92-22da792c530a@github.com>

On Wed, 10 Sep 2025 09:38:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include the prefix argument when calling FLAGS_COMPILER_CHECK_ARGUMENTS

I agree, that seems much better. That way it is also trivial to fix the `auto` case, which I believe is broken now -- the point is that with auto, we should turn on the flag if it is possible, otherwise we should turn off it. Not having the functionality is not an error nor should it print a warning -- just information that the functionality is not present, so it is turned off.

This test should be done *before* UTIL_ARG_ENABLE, and the result of whether the functionality is present or not should be passed as true/false in the AVAILABLE argument to UTIL_ARG_ENABLE. 

I would recommend you to have a look at how ENABLE_FULL_DOCS is setup in jdk-options.m4. I think this test should be handled in a similar way.

If the test is simple (I don't think it is in this case), it can also be inlined as a "lambda" with CHECK_AVAILABLE. (For that, see for instance how UBSAN_ENABLED is setup).

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3275233238

From syan at openjdk.org  Wed Sep 10 14:43:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 10 Sep 2025 14:43:38 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v10]
In-Reply-To: <raivjXzZZIs0hqK7uSJ8fdh9lJM4RiSicG8rqvrqfA4=.631cb0a3-50a3-4778-b92c-5b9428e6cbeb@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <raivjXzZZIs0hqK7uSJ8fdh9lJM4RiSicG8rqvrqfA4=.631cb0a3-50a3-4778-b92c-5b9428e6cbeb@github.com>
Message-ID: <OwCtaitSB6ntcTxQyq9HNFgxgNl5dih0lQ6LntS8QDU=.d5af9cbd-8082-4c9d-abb0-bf6822dd97bc@github.com>

On Wed, 10 Sep 2025 14:30:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use FLAGS_CPU and FLAGS_OS instead of OPENJDK_TARGET_CPU and OPENJDK_TARGET_OS to make cross-compile works normally

> I agree, that seems much better. That way it is also trivial to fix the `auto` case, which I believe is broken now -- the point is that with auto, we should turn on the flag if it is possible, otherwise we should turn off it. Not having the functionality is not an error nor should it print a warning -- just information that the functionality is not present, so it is turned off.
> 
> This test should be done _before_ UTIL_ARG_ENABLE, and the result of whether the functionality is present or not should be passed as true/false in the AVAILABLE argument to UTIL_ARG_ENABLE.
> 
> I would recommend you to have a look at how ENABLE_FULL_DOCS is setup in jdk-options.m4. I think this test should be handled in a similar way.
> 
> If the test is simple (I don't think it is in this case), it can also be inlined as a "lambda" with CHECK_AVAILABLE. (For that, see for instance how UBSAN_ENABLED is setup).

Thanks @erikj79 @magicus . I will try it later.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3275294162

From jiangli at openjdk.org  Wed Sep 10 14:46:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 Sep 2025 14:46:58 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
Message-ID: <QHj9p6HyMcAfmdnKXtS9L5tBvJcAbSz3i-1L31PNQ-4=.6862f545-f073-4df9-b467-8d147fb1b093@github.com>

On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
> 
> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.

> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.

@magicus I'll take a look today.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3275307649

From jiangli at openjdk.org  Thu Sep 11 00:19:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 11 Sep 2025 00:19:22 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
Message-ID: <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>

On Tue, 9 Sep 2025 13:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review

src/java.base/share/native/launcher/main.c line 41:

> 39: 
> 40: // This is reported when requesting a full version
> 41: static char* launcher = LAUNCHER_NAME;

Is it guaranteed that `LAUNCHER_NAME` is always defined at build time? Is it safer to keep the `ifdef LAUNCHER_NAME` check and initialize `launcer` to `NULL` if `LAUNCHER_NAME` is not defined? From removed defines.h:


#ifdef LAUNCHER_NAME
static const char* const_launcher = LAUNCHER_NAME;
#else  /* LAUNCHER_NAME */
static char* const_launcher = NULL;
#endif /* LAUNCHER_NAME */

src/java.base/share/native/launcher/main.c line 44:

> 42: 
> 43: // This is used as the name of the executable in the help message
> 44: static char* progname = PROGNAME;

Same question for `PROGNAME` as the one for `LAUNCHER_NAME` above.

src/java.base/share/native/launcher/main.c line 61:

> 59:         cpwildcard = JNI_FALSE;
> 60:     }
> 61:     if (strncmp(arg, "-J-DjavaLauncherProgname=", 26) == 0) {

It's better to replace the hardcoded string length with `strlen()` or `JLI_StrLen()`, e.g.:


const char *progname_prefix = "-J-DjavaLauncherProgname=";
int progname_prefix_len = strlen(progname_prefix);
if (strncmp(arg, "-J-DjavaLauncherProgname=", progname_prefix_len) == 0) {
    progname = arg + progname_prefix_len;
...

src/java.base/windows/native/launcher/relauncher.c line 1:

> 1: /*

How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338153342
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338163122
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338170678
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338210218

From jiangli at openjdk.org  Thu Sep 11 00:43:17 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 11 Sep 2025 00:43:17 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <SBqjB2IdVsSfLxZPHACn-WpL7SjAA3RUfVhfUz2MNcs=.de69ae1e-d2e5-4311-b685-80937e6fcc3e@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
 <SBqjB2IdVsSfLxZPHACn-WpL7SjAA3RUfVhfUz2MNcs=.de69ae1e-d2e5-4311-b685-80937e6fcc3e@github.com>
Message-ID: <ra0gZVkfNevC-n1B4qdO0IsNltzIDOaSjidNTvOrhmA=.37b483cc-9947-45f3-ad01-1d27318ee6fe@github.com>

On Wed, 10 Sep 2025 12:28:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
>> 
>> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.
>
> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.

> @magicus I'll take a look today.

Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3276985687

From alanb at openjdk.org  Thu Sep 11 06:35:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Sep 2025 06:35:42 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
Message-ID: <roICScHl9Q-E1w3lfQEwvi2xmSsnx3BjD5a8ig5KpS8=.9083d411-cc6b-4b3b-bb39-fa2cb9aee524@github.com>

On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
> 
> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.

> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.

ACK, I'll get to it shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3278424046

From syan at openjdk.org  Thu Sep 11 06:51:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 06:51:21 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v10]
In-Reply-To: <raivjXzZZIs0hqK7uSJ8fdh9lJM4RiSicG8rqvrqfA4=.631cb0a3-50a3-4778-b92c-5b9428e6cbeb@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <raivjXzZZIs0hqK7uSJ8fdh9lJM4RiSicG8rqvrqfA4=.631cb0a3-50a3-4778-b92c-5b9428e6cbeb@github.com>
Message-ID: <gXJEwYWpzyXV7JnGCt_NTTkhYwSeF608DXvl--38Jtc=.1f5c0e12-7493-48f6-9a36-55900fc7a8a8@github.com>

On Wed, 10 Sep 2025 14:30:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use FLAGS_CPU and FLAGS_OS instead of OPENJDK_TARGET_CPU and OPENJDK_TARGET_OS to make cross-compile works normally

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/27073#issuecomment-3278549014

From matthias.baesken at sap.com  Thu Sep 11 09:09:19 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 11 Sep 2025 09:09:19 +0000
Subject: Mixture of product and fastdebug builds in GHA
In-Reply-To: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>

>So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ?
>If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug  ?


I checked the GHA settings from

https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml

And found that on Linux we build already (fast)debug. That?s good !
But seems we miss it on e.g. macOS   and also Windows  .
Could we adjust the GHA settings or add a 3rd macOS build  using (fast)debug   ?


Best regards, Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250911/76d38393/attachment.htm>

From ihse at openjdk.org  Thu Sep 11 09:30:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 09:30:53 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
 <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>
Message-ID: <mbY8yNkKFkq8b2hnCrPWrO0yj4o-wvBozqGFUVpkzYw=.e3773a87-4d93-47fb-9d7d-32becd684fee@github.com>

On Wed, 10 Sep 2025 23:29:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review
>
> src/java.base/share/native/launcher/main.c line 41:
> 
>> 39: 
>> 40: // This is reported when requesting a full version
>> 41: static char* launcher = LAUNCHER_NAME;
> 
> Is it guaranteed that `LAUNCHER_NAME` is always defined at build time? Is it safer to keep the `ifdef LAUNCHER_NAME` check and initialize `launcer` to `NULL` if `LAUNCHER_NAME` is not defined? From removed defines.h:
> 
> 
> #ifdef LAUNCHER_NAME
> static const char* const_launcher = LAUNCHER_NAME;
> #else  /* LAUNCHER_NAME */
> static char* const_launcher = NULL;
> #endif /* LAUNCHER_NAME */

Yes, it is guaranteed. It is always passed by the make files, and have been for a very long time. That ifdef has not been needed since the "new" build system, so maybe it was needed in JDK 7 or prior...

> src/java.base/windows/native/launcher/relauncher.c line 1:
> 
>> 1: /*
> 
> How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows?

Yes, static JDK is supported on all supported platforms.

I just ran simple adhoc tests on the command line, checking that a select subset of the launchers worked, like jar, jlink and javac. My assumption was that if they just started fine, then there were no reason to test the full functionality, since this patch is just about getting them launched.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339724736
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339737476

From ihse at openjdk.org  Thu Sep 11 09:40:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 09:40:58 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v7]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <wrvmDCiyifv_is0GvIJRKxzghEaC_fSFV58fZE-T7AQ=.2766d0db-789d-451e-ae01-cd4d942fe71e@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into static-relaunchers
 - Update based on review
 - Merge branch 'master' into static-relaunchers
 - Use ReadFile instead
 - Merge branch 'master' into static-relaunchers
 - Remove problemlisting
 - Merge branch 'master' into static-relaunchers
 - Improve windows runtime lib copying
 - Fix linux launcher to allow relaunching
 - Copy Windows runtime libs
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3d679087...62980659

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

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=06
  Stats: 814 lines in 14 files changed: 624 ins; 144 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380

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

From ihse at openjdk.org  Thu Sep 11 09:41:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 09:41:01 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
 <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>
Message-ID: <42eBed988TwesF1JmAa_QD48HKU0bRGQcz7nPR32Xmk=.c5c4566a-6a9e-4098-be1e-e8f3f1de8b05@github.com>

On Wed, 10 Sep 2025 23:36:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review
>
> src/java.base/share/native/launcher/main.c line 44:
> 
>> 42: 
>> 43: // This is used as the name of the executable in the help message
>> 44: static char* progname = PROGNAME;
> 
> Same question for `PROGNAME` as the one for `LAUNCHER_NAME` above.

And same reply here. It is always passed from the makefile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339780842

From ihse at openjdk.org  Thu Sep 11 09:41:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 09:41:04 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v6]
In-Reply-To: <mbY8yNkKFkq8b2hnCrPWrO0yj4o-wvBozqGFUVpkzYw=.e3773a87-4d93-47fb-9d7d-32becd684fee@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <lV-7YwC0mwwtD8Wth1__GFEcC7MmWNBEquirCZkYEbU=.3b6af12e-ce2b-4b77-9223-819fd6180c6b@github.com>
 <Kz2tESkG_W5Q_zUKxQNO_fgTk9nijWZpvh1QS3qyGtA=.ba6477ab-a9ed-419a-b46b-5551e80e73ab@github.com>
 <mbY8yNkKFkq8b2hnCrPWrO0yj4o-wvBozqGFUVpkzYw=.e3773a87-4d93-47fb-9d7d-32becd684fee@github.com>
Message-ID: <zalgF1EEHJNGfC3_H1BWlFLYplRM96l7LlECNqCFnFg=.99e253ed-777f-441e-92e6-dbdacca2abb5@github.com>

On Thu, 11 Sep 2025 09:27:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/windows/native/launcher/relauncher.c line 1:
>> 
>>> 1: /*
>> 
>> How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows?
>
> Yes, static JDK is supported on all supported platforms.
> 
> I just ran simple adhoc tests on the command line, checking that a select subset of the launchers worked, like jar, jlink and javac. My assumption was that if they just started fine, then there were no reason to test the full functionality, since this patch is just about getting them launched.

Also, I've emptied the problem lists for static builds. (I kept the actual ProblemList files for now, if it turns out we find other tests that are problematic.) If there was a problem with launching e.g. `jar`, then those tests should have failed.

Now it has passed some time since I ran the tests, so I'll start a comprehensive test suite again on this PR, just to make sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339753600

From syan at openjdk.org  Thu Sep 11 09:43:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 09:43:36 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v11]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <JD3NwxAMbWEJzAKpMMLCz2VOVIXTcnb2WSeOsMuJVwU=.87040427-ff56-4a1b-9119-6c1523ded48a@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Use lambda with CHECK_AVAIABLE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/1171cfa5..5f166051

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

  Stats: 96 lines in 2 files changed: 36 ins; 43 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27073/head:pull/27073

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

From ihse at openjdk.org  Thu Sep 11 10:07:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 10:07:05 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v8]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <ELESYI9muEM3mEeGTjKgPPElNcZu5j-QbRjdIEV9Rlg=.5624f51f-b978-402c-b4f5-04e814642588@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use strlen to get literal string lenght

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24380/files
  - new: https://git.openjdk.org/jdk/pull/24380/files/62980659..9881813d

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

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

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

From ihse at openjdk.org  Thu Sep 11 12:13:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 12:13:04 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove debug code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24380/files
  - new: https://git.openjdk.org/jdk/pull/24380/files/9881813d..e9925dab

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

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

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

From ihse at openjdk.org  Thu Sep 11 12:13:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 12:13:14 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v11]
In-Reply-To: <JD3NwxAMbWEJzAKpMMLCz2VOVIXTcnb2WSeOsMuJVwU=.87040427-ff56-4a1b-9119-6c1523ded48a@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <JD3NwxAMbWEJzAKpMMLCz2VOVIXTcnb2WSeOsMuJVwU=.87040427-ff56-4a1b-9119-6c1523ded48a@github.com>
Message-ID: <t3Ij66TZ6Lp1WyE8KD03h-Eiy1OJAyKcwGHS8g12UYA=.29611601-9d19-4d5f-8fb3-2f02b95017d8@github.com>

On Thu, 11 Sep 2025 09:43:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lambda with CHECK_AVAIABLE

There were a major refactoring regarding the timeout factor. This can cause various tests to trigger timeout in the aftermath. It's good that you tracked it but I wouldn't worry too much about it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3280279954

From ihse at openjdk.org  Thu Sep 11 12:13:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Sep 2025 12:13:06 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <ra0gZVkfNevC-n1B4qdO0IsNltzIDOaSjidNTvOrhmA=.37b483cc-9947-45f3-ad01-1d27318ee6fe@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
 <SBqjB2IdVsSfLxZPHACn-WpL7SjAA3RUfVhfUz2MNcs=.de69ae1e-d2e5-4311-b685-80937e6fcc3e@github.com>
 <ra0gZVkfNevC-n1B4qdO0IsNltzIDOaSjidNTvOrhmA=.37b483cc-9947-45f3-ad01-1d27318ee6fe@github.com>
Message-ID: <jqAdLXFi0l27tUmC9K9Aun-jwMwKNCAt87gJnvIDYbM=.f4a5a939-687b-464a-a86f-1e4a3a97ad57@github.com>

On Thu, 11 Sep 2025 00:39:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.
>
>> @magicus I'll take a look today.
> 
> Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor.

I just realized that the testing I kicked off (tier1-5 on our internal CI) does not include running tests using the static-jdk. @jianglizhou Do you have any recommendation to the easiest way to use the static-jdk for testing?

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3280273927

From syan at openjdk.org  Thu Sep 11 12:38:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 12:38:20 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v11]
In-Reply-To: <JD3NwxAMbWEJzAKpMMLCz2VOVIXTcnb2WSeOsMuJVwU=.87040427-ff56-4a1b-9119-6c1523ded48a@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <JD3NwxAMbWEJzAKpMMLCz2VOVIXTcnb2WSeOsMuJVwU=.87040427-ff56-4a1b-9119-6c1523ded48a@github.com>
Message-ID: <Di32gL5oxN4HFYBH4M4ODMJpVhWiQaf2q-v67i8E3mI=.f2569f90-e1aa-4d11-8f2e-c2259ed3da7d@github.com>

On Thu, 11 Sep 2025 09:43:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lambda with CHECK_AVAIABLE

Job https://github.com/sendaoYan/jdk-ysd/actions/runs/17640542609/job/50126351415 report build fails, since the compiler(clang-15) on macos-aarch64 generate Segmentation fault error with -march=armv8-a+sve option when buiding the libsleef. This because the [patchset](https://github.com/openjdk/jdk/pull/27073/commits/5f16605149369456b3fdd9a0b1fb229d3d6388e2) make aarch64-sve enable by default. The `UTIL_ARG_ENABLE(NAME: aarch64-sve)` has no change to be invoked during configure stage. It's no expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3280414263

From syan at openjdk.org  Thu Sep 11 12:44:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 12:44:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v12]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <QErbPY9YPu-IsAYm9j6pxdAQ_lpw7ytGPOXDaQngS8I=.db88c033-b96d-43c0-b531-13f3f696aa6d@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Fix CFLAGS save bugs after "Use lambda with CHECK_AVAIABLE"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/5f166051..98237c10

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

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

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

From erikj at openjdk.org  Thu Sep 11 13:13:28 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Sep 2025 13:13:28 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v12]
In-Reply-To: <QErbPY9YPu-IsAYm9j6pxdAQ_lpw7ytGPOXDaQngS8I=.db88c033-b96d-43c0-b531-13f3f696aa6d@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <QErbPY9YPu-IsAYm9j6pxdAQ_lpw7ytGPOXDaQngS8I=.db88c033-b96d-43c0-b531-13f3f696aa6d@github.com>
Message-ID: <rNc9MiG7d0GX5owhpDfZUsMHB0fTK0k-iu3JmJqw2nM=.a9e03504-2291-4028-93bf-2d68602b2bb5@github.com>

On Thu, 11 Sep 2025 12:44:42 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix CFLAGS save bugs after "Use lambda with CHECK_AVAIABLE"

I would suggest creating a separate `FLAGS_SETUP_SVE`, called from `FLAGS_SETUP_FLAGS` and put the whole thing in there.

make/autoconf/flags-cflags.m4 line 953:

> 951:         IF_TRUE: [
> 952:           $2SVE_CFLAGS="${$2SVE_CFLAGS} $INIT_ZERO_FLAG"
> 953:         ]

This should also be moved out of `FLAGS_SETUP_CFLAGS_CPU_DEP`. The role of the macro `FLAGS_SETUP_CFLAGS_CPU_DEP` is to be run twice, once for the target compiler and once for the build compiler. If we have concluded that the sve flags are irrelevant to the build compiler and only want to do this once for just the target compiler, then it shouldn't be in this macro. The whole thing needs to be outside of it and be run explicitly against just the target compiler. I think it can all be inlined in the macro call to `UTIL_ARG_ENABLE`.

make/autoconf/flags.m4 line 377:

> 375:       # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
> 376:       # that check.
> 377:       if test "x$FLAGS_CPU" = "xaarch64" && test "x$FLAGS_OS" = "xlinux"; then

If moving this outside of `FLAGS_SETUP_CFLAGS_CPU_DEP`, then these variables don't exist anymore.

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

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3211450697
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2340776092
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2340763819

From syan at openjdk.org  Thu Sep 11 14:11:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 14:11:39 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Create a seperate macro FLAGS_SETUP_SVE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/98237c10..923aae9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=11-12

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

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

From syan at openjdk.org  Thu Sep 11 14:11:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 11 Sep 2025 14:11:42 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v12]
In-Reply-To: <rNc9MiG7d0GX5owhpDfZUsMHB0fTK0k-iu3JmJqw2nM=.a9e03504-2291-4028-93bf-2d68602b2bb5@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <QErbPY9YPu-IsAYm9j6pxdAQ_lpw7ytGPOXDaQngS8I=.db88c033-b96d-43c0-b531-13f3f696aa6d@github.com>
 <rNc9MiG7d0GX5owhpDfZUsMHB0fTK0k-iu3JmJqw2nM=.a9e03504-2291-4028-93bf-2d68602b2bb5@github.com>
Message-ID: <pi6RLxeB-G8U88HxhUW-muTnuQJr1Zec-j1Ok0GhKh4=.25db9668-f63f-4e8c-9090-2b4f09fe46f9@github.com>

On Thu, 11 Sep 2025 13:09:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I would suggest creating a separate `FLAGS_SETUP_SVE`, called from `FLAGS_SETUP_FLAGS` and put the whole thing in there.

Thanks, I have created a separate macro `FLAGS_SETUP_SVE` located in make/autoconf/flags-other.m4. I am not quite sure which file should be belonged.

> make/autoconf/flags.m4 line 377:
> 
>> 375:       # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
>> 376:       # that check.
>> 377:       if test "x$FLAGS_CPU" = "xaarch64" && test "x$FLAGS_OS" = "xlinux"; then
> 
> If moving this outside of `FLAGS_SETUP_CFLAGS_CPU_DEP`, then these variables don't exist anymore.

Thanks, fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3280953137
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2341043906

From erikj at openjdk.org  Thu Sep 11 21:19:24 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Sep 2025 21:19:24 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
Message-ID: <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>

On Thu, 11 Sep 2025 14:11:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create a seperate macro FLAGS_SETUP_SVE

This definitely looks better but still some things that can be improved.

make/autoconf/flags-other.m4 line 116:

> 114:   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
> 115:     RESULT: AARCH64_SVE_ENABLED,
> 116:     DESC: [Use SVE when compile libsleef],

Suggestion:

    DESC: [Use SVE when compiling libsleef],

make/autoconf/flags-other.m4 line 119:

> 117:     CHECK_AVAILABLE: [
> 118:       # Check whether the compiler supports the Arm C Language Extensions (ACLE)
> 119:       # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.

This comment is a bit out of date with the code now. This is just the check available part. Maybe move this to before the macro call?

make/autoconf/flags-other.m4 line 140:

> 138:           ])],
> 139:           [AVAILABLE=yes],
> 140:           [AVAILABLE=no]

The documentation of `UTIL_ARG_ENABLE` says that `AVAILABLE` needs to be set to `false` when not available.

make/autoconf/flags-other.m4 line 146:

> 144:         CFLAGS="$saved_cflags"
> 145:         AC_LANG_POP([C])
> 146:       fi

I think we need `AVAILABLE=fallse` when not matching the toolchain. This can also be expressed as `AVAILABLE: false` as a parameter to `UTIL_ARG_ENABLE`. The `CHECK_AVAILABLE` gets a chance to overwrite that value.

make/autoconf/flags-other.m4 line 167:

> 165:     fi
> 166:     CFLAGS="$OLD_CFLAGS"
> 167:     AC_LANG_POP(C)

This part should be included in the `IF_ENABLED` block in `UTIL_ARG_ENABLE`.

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

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3213638099
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342338970
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342341790
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342355196
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342354523
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342359541

From jiangli at openjdk.org  Fri Sep 12 01:08:25 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 12 Sep 2025 01:08:25 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <ra0gZVkfNevC-n1B4qdO0IsNltzIDOaSjidNTvOrhmA=.37b483cc-9947-45f3-ad01-1d27318ee6fe@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
 <SBqjB2IdVsSfLxZPHACn-WpL7SjAA3RUfVhfUz2MNcs=.de69ae1e-d2e5-4311-b685-80937e6fcc3e@github.com>
 <ra0gZVkfNevC-n1B4qdO0IsNltzIDOaSjidNTvOrhmA=.37b483cc-9947-45f3-ad01-1d27318ee6fe@github.com>
Message-ID: <6Qp-kHEVhsLq2Bdl1mmvIS2i5egm0pKkB8bjzux3iwo=.e69ceb75-06c4-45e6-a71b-2138c89c1e92@github.com>

On Thu, 11 Sep 2025 00:39:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.
>
>> @magicus I'll take a look today.
> 
> Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor.

> I just realized that the testing I kicked off (tier1-5 on our internal CI) does not include running tests using the static-jdk. @jianglizhou Do you have any recommendation to the easiest way to use the static-jdk for testing?

We enabled running jtreg tests on static-jdk in GHA (https://github.com/openjdk/jdk/commit/16d45511342c32ac8e8f72fb68dc21ce13339dbe). It sets `JDK_UNDER_TEST=<static-jdk-path>`, `JDK_FOR_COMPILE=<regular-jdk-path>` and `extra-problem-lists` with .github/workflows/test.yml to run tests on static-jdk. Probably relatively easy to setup with tired testing as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3283164409

From kbarrett at openjdk.org  Fri Sep 12 01:21:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 12 Sep 2025 01:21:35 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
Message-ID: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>

Please review this change to the HotSpot Style Guide to permit the use of
variable templates. This is a C++14 feature that, while fairly simple, didn't
get into the initial permitted for HotSpot list because I just didn't get to
it and nobody asked for it. And it has languished on the "undecided" list for
the same reasons. But recently I've had reason to want to use this feature a
couple of times, so I'm now proposing we allow it.

I merged it into the section for Inline Variables (a C++17 feature), as the
two are closely related. Variable templates were even listed as one of the
workarounds being used to make up for the lack of inline variables.

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

Commit messages:
 - permit variable templates

Changes: https://git.openjdk.org/jdk/pull/27240/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27240&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252582
  Stats: 50 lines in 2 files changed: 15 ins; 7 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27240/head:pull/27240

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

From david.holmes at oracle.com  Fri Sep 12 01:40:13 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Sep 2025 11:40:13 +1000
Subject: Mixture of product and fastdebug builds in GHA
In-Reply-To: <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <a094307e-f6ae-4e22-a9bf-508281d96962@oracle.com>

Hi Matthias,

On 11/09/2025 7:09 pm, Baesken, Matthias wrote:
>>So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ?
> 
>>If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug? ?
> 
> I checked the GHA settings from
> 
> https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml 
> <https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml>
> 
> And found that on Linux we build already (fast)debug. That?s good !
> 
> But seems we miss it on e.g. macOS?? and also Windows ?.
> 
> Could we adjust the GHA settings or add a 3rd macOS build? using 
> (fast)debug?? ?

Ideally of course we would test as much as we can, but this isn't a 
technical question. Even Github has limits on how much workload it can 
handle so if we enable more platforms we may experience delays that are 
more detrimental overall than the impact of limited testing. I don't 
know who may know about the internal details here - @shipilev?

David
-----

> Best regards, Matthias
> 


From syan at openjdk.org  Fri Sep 12 02:03:05 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 02:03:05 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v14]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <PJmvlUdolxmadCxtJoAi-mprqqLhodTbn599aQ2JI10=.d978e870-fd6c-41b8-a94f-8957188c53db@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Use compiling replace as compile
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/923aae9c..b906a2a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=12-13

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

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

From dholmes at openjdk.org  Fri Sep 12 02:04:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Sep 2025 02:04:14 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <aHOl52_aY8MBWVYft2e_pFC5q1v4_F7TIdoULZNBhXg=.0a0c692d-441d-43e3-823c-5a212355aaca@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3214349356

From syan at openjdk.org  Fri Sep 12 02:15:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 02:15:55 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v15]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <SlSIJlDO9WT6gR6EMkzonhh3Ff_JW3BbJHxrekeFNOo=.15977fe1-64f5-4190-a0dc-ebdd83b5ac69@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

 - Move the description comment before the macro call
 - Add OPENJDK_TARGET_CPU and OPENJDK_TARGET_OS check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/b906a2a0..1f6d1d8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=13-14

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

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

From syan at openjdk.org  Fri Sep 12 02:15:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 02:15:56 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
 <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
Message-ID: <5U79-eebPHch5QfGCLpoMcdiM_XZWRYC30JhZxAimTE=.4ec10530-a371-4f58-89d4-796bbd5cf1d9@github.com>

On Thu, 11 Sep 2025 21:05:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create a seperate macro FLAGS_SETUP_SVE
>
> make/autoconf/flags-other.m4 line 119:
> 
>> 117:     CHECK_AVAILABLE: [
>> 118:       # Check whether the compiler supports the Arm C Language Extensions (ACLE)
>> 119:       # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
> 
> This comment is a bit out of date with the code now. This is just the check available part. Maybe move this to before the macro call?

Thanks, the description comment has been moved to before the macro called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342770993

From syan at openjdk.org  Fri Sep 12 03:48:44 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 03:48:44 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v16]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <BJRdOumz0MlFOKvnAGQ4BFMpWgoHeAB4BoNJSWt8q9k=.5260d313-0141-46ce-ac26-985cb801b93c@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

 - Set AVAILABLE=true/false
 - Add AVAILABLE: false as argument for UTIL_ARG_ENABLE
 - Comment adjust

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/1f6d1d8f..8834a40e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=14-15

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

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

From syan at openjdk.org  Fri Sep 12 03:48:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 03:48:46 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
 <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
Message-ID: <ReAaNkBHh2IzAHcA8Cz5AytB7mI7OiW_3qFrHS0Cy5w=.a6b9f42b-76d3-412d-b7e3-36bf865dab93@github.com>

On Thu, 11 Sep 2025 21:13:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create a seperate macro FLAGS_SETUP_SVE
>
> make/autoconf/flags-other.m4 line 140:
> 
>> 138:           ])],
>> 139:           [AVAILABLE=yes],
>> 140:           [AVAILABLE=no]
> 
> The documentation of `UTIL_ARG_ENABLE` says that `AVAILABLE` needs to be set to `false` when not available.

Thanks for the advice. Updated.

> make/autoconf/flags-other.m4 line 146:
> 
>> 144:         CFLAGS="$saved_cflags"
>> 145:         AC_LANG_POP([C])
>> 146:       fi
> 
> I think we need `AVAILABLE=fallse` when not matching the toolchain. This can also be expressed as `AVAILABLE: false` as a parameter to `UTIL_ARG_ENABLE`. The `CHECK_AVAILABLE` gets a chance to overwrite that value.

Thanks for the advice. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342866398
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2342866074

From stefank at openjdk.org  Fri Sep 12 05:59:14 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Sep 2025 05:59:14 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <aqVwQKleJAihbCsd-Oj0YPERBG_o6Gtw_gQ4mpQqxMk=.f7e34cad-94fc-4050-bbd8-5e684f6c14ec@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3214768117

From syan at openjdk.org  Fri Sep 12 07:00:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 07:00:23 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
 <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
Message-ID: <ZQKGL0QWS_pbF1igUPPxoTwt4LF_PAobwnA8-f8KFvE=.4e24e030-3791-42c0-bb81-f249db1d6a0c@github.com>

On Thu, 11 Sep 2025 21:16:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create a seperate macro FLAGS_SETUP_SVE
>
> make/autoconf/flags-other.m4 line 167:
> 
>> 165:     fi
>> 166:     CFLAGS="$OLD_CFLAGS"
>> 167:     AC_LANG_POP(C)
> 
> This part should be included in the `IF_ENABLED` block in `UTIL_ARG_ENABLE`.

The `FLAGS_COMPILER_CHECK_ARGUMENTS` macro seem do not work normally in `IF_ENABLED:` block. The 'bash configure' command report "Internal error: Argument DEFAULT to UTIL_ARG_ENABLE can only be true, false or auto, was: ARG_DEFAULT". Below is the implementation.


AC_DEFUN([FLAGS_SETUP_SVE],
[
  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
    RESULT: AARCH64_SVE_ENABLED,
    DESC: [Use SVE when compiling libsleef],
    AVAILABLE: false,
    CHECK_AVAILABLE: [
      # Apple Silicon does not support SVE; use macOS as a proxy for that check.
      if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
        if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
          # check the compiler and binutils support sve or not
          AC_MSG_CHECKING([if Arm SVE ACLE is supported])
          AC_LANG_PUSH([C])
          saved_cflags="$CFLAGS"
          saved_cc="$CC"
          CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS ARG_ARGUMENT"
          CC="$ARG_PREFIX[CC]"
          AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
            [
              #include <arm_sve.h>
              svfloat64_t a() {}
            ],
            [
              svint32_t r = svdup_n_s32(1)
            ])],
            [AVAILABLE=true],
            [AVAILABLE=false]
          )
          AC_MSG_RESULT([$AVAILABLE])
          CC="$saved_cc"
          CFLAGS="$saved_cflags"
          AC_LANG_POP([C])
        fi
      fi
    ],
    IF_ENABLED: [
      SVE_CFLAGS="-march=armv8-a+sve"
      # Switching the initialization mode with gcc from 'pattern' to 'zero'
      # avoids the use of unsupported `__builtin_clear_padding` for variable
      # length aggregates
      if test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
        AC_MSG_CHECKING([Switching the initialization mode with gcc from pattern to zero])
        INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
        FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],
          IF_TRUE: [SVE_CFLAGS="${SVE_CFLAGS} $INIT_ZERO_FLAG"])
      fi
    ]
    )
  AC_SUBST(SVE_CFLAGS)
])

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2343202947

From duke at openjdk.org  Fri Sep 12 07:58:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Sep 2025 07:58:39 GMT
Subject: Withdrawn: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <CYjrMQ9q7paO0oYq8KGvDJaUV2FpwdJyUFxwY16oeK0=.c1e98154-834e-453d-8a00-c4fae4c1a233@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

This pull request has been closed without being integrated.

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

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

From shipilev at amazon.de  Fri Sep 12 08:26:49 2025
From: shipilev at amazon.de (Shipilev, Aleksey)
Date: Fri, 12 Sep 2025 08:26:49 +0000
Subject: Mixture of product and fastdebug builds in GHA
In-Reply-To: <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <18E81675-6FED-4999-B557-7BDAF229761E@amazon.de>

Hi,

I don?t understand what the exact problem is here. Have you had a build or a test failing that was not caught by GHA?

We build both fastdebug and release for all platforms that run tests. Take a look into any GHA run, for example, https://github.com/shipilev/jdk/actions/runs/17491480307 -- you can clearly see macos-(x64|aarch64) build (debug|release) jobs.

What *is* awkward in current GHA configs: non-Hotspot tests are executed with release bits, while Hotspot tests are executed with fastdebug. So if you run fastdebug tier1 testing locally, it will not be 100% the same thing GHA runs. Arguably, we want to run all tests with fastdebug, really, but I never got to trying that in GHA. This would probably make tests slower. I am pretty sure GHA infra could handle it, it is only the question how much slower the testing would become.

-Aleksey


From: build-dev <build-dev-retn at openjdk.org> on behalf of "Baesken, Matthias" <matthias.baesken at sap.com>
Date: Thursday, 11. September 2025 at 11:09
To: "build-dev at openjdk.org" <build-dev at openjdk.org>
Cc: "Zeller, Arno" <arno.zeller at sap.com>, "Langer, Christoph" <christoph.langer at sap.com>, "Bechberger, Johannes" <johannes.bechberger at sap.com>
Subject: RE: [EXTERNAL] Mixture of product and fastdebug builds in GHA


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


>So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ?
>If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug  ?


I checked the GHA settings from

https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml

And found that on Linux we build already (fast)debug. That?s good !
But seems we miss it on e.g. macOS   and also Windows  .
Could we adjust the GHA settings or add a 3rd macOS build  using (fast)debug   ?


Best regards, Matthias





Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250912/73407ea6/attachment-0001.htm>

From syan at openjdk.org  Fri Sep 12 08:51:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 08:51:50 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v17]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <pPdoMDNLgfZjBDA0gI3kDBe_BFgjTTsvWBejxVkqfMU=.6de57e3e-3dd0-43d3-85ff-d7a3ea584bba@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

  Remove unnecessary CFLAGS save and restore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/8834a40e..350ac24d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=15-16

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

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

From matthias.baesken at sap.com  Fri Sep 12 09:32:51 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 12 Sep 2025 09:32:51 +0000
Subject: Mixture of product and fastdebug builds in GHA
In-Reply-To: <18E81675-6FED-4999-B557-7BDAF229761E@amazon.de>
References: <DU2PR02MB1025876D6FC75E2805EC736C39303A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <DU2PR02MB1025827A3E08CAAF29095393A9309A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <18E81675-6FED-4999-B557-7BDAF229761E@amazon.de>
Message-ID: <DU2PR02MB10258EBCA88D2B502BB2F327C9308A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi Aleksey,  indeed we had some commit of  a  PR   (I think it was related to 8366082 ?)
that recently failed building in all  non-Linux  fastdebug builds.
And I did not see related issues in GHA, that is strange .

So to sum it up, we already have  fastdebug  not ony on Linux but also on macOS/Windows.
This is a good thing!

Best regards, Matthias


From: Shipilev, Aleksey <shipilev at amazon.de>
Sent: Friday, 12 September 2025 10:27
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.org
Cc: Zeller, Arno <arno.zeller at sap.com>; Langer, Christoph <christoph.langer at sap.com>; Bechberger, Johannes <johannes.bechberger at sap.com>
Subject: Re: Mixture of product and fastdebug builds in GHA

Hi,

I don?t understand what the exact problem is here. Have you had a build or a test failing that was not caught by GHA?

We build both fastdebug and release for all platforms that run tests. Take a look into any GHA run, for example, https://github.com/shipilev/jdk/actions/runs/17491480307 -- you can clearly see macos-(x64|aarch64) build (debug|release) jobs.

What *is* awkward in current GHA configs: non-Hotspot tests are executed with release bits, while Hotspot tests are executed with fastdebug. So if you run fastdebug tier1 testing locally, it will not be 100% the same thing GHA runs. Arguably, we want to run all tests with fastdebug, really, but I never got to trying that in GHA. This would probably make tests slower. I am pretty sure GHA infra could handle it, it is only the question how much slower the testing would become.

-Aleksey


From: build-dev <build-dev-retn at openjdk.org<mailto:build-dev-retn at openjdk.org>> on behalf of "Baesken, Matthias" <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
Date: Thursday, 11. September 2025 at 11:09
To: "build-dev at openjdk.org<mailto:build-dev at openjdk.org>" <build-dev at openjdk.org<mailto:build-dev at openjdk.org>>
Cc: "Zeller, Arno" <arno.zeller at sap.com<mailto:arno.zeller at sap.com>>, "Langer, Christoph" <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>, "Bechberger, Johannes" <johannes.bechberger at sap.com<mailto:johannes.bechberger at sap.com>>
Subject: RE: [EXTERNAL] Mixture of product and fastdebug builds in GHA


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

>So does that mean, that we build all GHA builds with debug level release/product and none with fastdebug ?
>If so, could we maybe in future use some mixture, like most product but a few e.g. one on Linux one on macOS fastdebug  ?


I checked the GHA settings from

https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml

And found that on Linux we build already (fast)debug. That?s good !
But seems we miss it on e.g. macOS   and also Windows  .
Could we adjust the GHA settings or add a 3rd macOS build  using (fast)debug   ?


Best regards, Matthias





Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250912/e225436e/attachment-0001.htm>

From erikj at openjdk.org  Fri Sep 12 13:13:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Sep 2025 13:13:39 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v17]
In-Reply-To: <pPdoMDNLgfZjBDA0gI3kDBe_BFgjTTsvWBejxVkqfMU=.6de57e3e-3dd0-43d3-85ff-d7a3ea584bba@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <pPdoMDNLgfZjBDA0gI3kDBe_BFgjTTsvWBejxVkqfMU=.6de57e3e-3dd0-43d3-85ff-d7a3ea584bba@github.com>
Message-ID: <GvzwL9j2N5-1DFFMHXLbeKjMG88LvjoXfm5ajWH3sS0=.c0540742-09ad-4b82-a27d-1d1107759d68@github.com>

On Fri, 12 Sep 2025 08:51:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary CFLAGS save and restore

It's very close to ok now.

make/autoconf/flags-other.m4 line 128:

> 126:           saved_cc="$CC"
> 127:           CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS ARG_ARGUMENT"
> 128:           CC="$ARG_PREFIX[CC]"

You shouldn't need to save `CC` and use a custom one here. `CC` should be the target compiler already.

make/autoconf/flags-other.m4 line 140:

> 138:             [AVAILABLE=false]
> 139:           )
> 140:           AC_MSG_RESULT([$AVAILABLE])

This will now print true/false instead of yes/no, which will look a bit weird. It's a consequence of us preferring `true/false` to express booleans internally. I think I would inline the call to `AC_MSG_RESULT` in each of the branches of `AC_COMPILE_IFELSE` to work around this.

make/autoconf/flags.m4 line 380:

> 378:   # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
> 379:   # ACLE and this flag are required to build the aarch64 SVE related functions
> 380:   # in libvectormath.

I think you misunderstood me here, I meant move it to the top of the macro declaration, not the call. I think it makes more sense to document it where it's defined.

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

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3216584548
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344191092
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344204464
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344185294

From erikj at openjdk.org  Fri Sep 12 13:13:41 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Sep 2025 13:13:41 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v13]
In-Reply-To: <ZQKGL0QWS_pbF1igUPPxoTwt4LF_PAobwnA8-f8KFvE=.4e24e030-3791-42c0-bb81-f249db1d6a0c@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <Btny_ocuo2ImwcMnnwKXtXFz10bo3r06hunj4cfW-aY=.8cb43540-bcc3-446a-a9da-13244f7816fa@github.com>
 <SpwaNhBR2-pqR0IQ9XKD-Eu0RcNyKJII8f0TYe88VAM=.03a75932-9429-4b37-b3db-11db4a9d8cdc@github.com>
 <ZQKGL0QWS_pbF1igUPPxoTwt4LF_PAobwnA8-f8KFvE=.4e24e030-3791-42c0-bb81-f249db1d6a0c@github.com>
Message-ID: <H4pkYAWdUX_oyUuX_9zJY3WZ-zE9ZQBVWFGLoDxAsaE=.bbd27913-5ac4-4895-a36f-6da47ee2b959@github.com>

On Fri, 12 Sep 2025 06:57:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> make/autoconf/flags-other.m4 line 167:
>> 
>>> 165:     fi
>>> 166:     CFLAGS="$OLD_CFLAGS"
>>> 167:     AC_LANG_POP(C)
>> 
>> This part should be included in the `IF_ENABLED` block in `UTIL_ARG_ENABLE`.
>
> The `FLAGS_COMPILER_CHECK_ARGUMENTS` macro seem do not work normally in `IF_ENABLED:` block. The 'bash configure' command report "Internal error: Argument DEFAULT to UTIL_ARG_ENABLE can only be true, false or auto, was: ARG_DEFAULT". Below is the implementation.
> 
> Even though I add `PREFIX: BUILD_` or `PREFIX: ` argument to `FLAGS_COMPILER_CHECK_ARGUMENTS` it still report the same error.
> 
> 
> AC_DEFUN([FLAGS_SETUP_SVE],
> [
>   UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>     RESULT: AARCH64_SVE_ENABLED,
>     DESC: [Use SVE when compiling libsleef],
>     AVAILABLE: false,
>     CHECK_AVAILABLE: [
>       # Apple Silicon does not support SVE; use macOS as a proxy for that check.
>       if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
>         if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>           # check the compiler and binutils support sve or not
>           AC_MSG_CHECKING([if Arm SVE ACLE is supported])
>           AC_LANG_PUSH([C])
>           saved_cflags="$CFLAGS"
>           saved_cc="$CC"
>           CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS ARG_ARGUMENT"
>           CC="$ARG_PREFIX[CC]"
>           AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
>             [
>               #include <arm_sve.h>
>               svfloat64_t a() {}
>             ],
>             [
>               svint32_t r = svdup_n_s32(1)
>             ])],
>             [AVAILABLE=true],
>             [AVAILABLE=false]
>           )
>           AC_MSG_RESULT([$AVAILABLE])
>           CC="$saved_cc"
>           CFLAGS="$saved_cflags"
>           AC_LANG_POP([C])
>         fi
>       fi
>     ],
>     IF_ENABLED: [
>       SVE_CFLAGS="-march=armv8-a+sve"
>       # Switching the initialization mode with gcc from 'pattern' to 'zero'
>       # avoids the use of unsupported `__builtin_clear_padding` for variable
>       # length aggregates
>       if test "x$DEBUG_LEVEL" != xrelease && test "x$TOOLCHAIN_TYPE" = xgcc ; then
>         AC_MSG_CHECKING([Switching the initialization mode with gcc from pattern to zero])
>         INIT_ZERO_FLAG="-ftrivial-auto-var-init=zero"
>         FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$INIT_ZERO_FLAG],
>           IF_TRUE: [SVE_CFLAGS="${SVE_CFLAGS} $INIT_ZERO_FLAG"])
>       fi
>     ]
>     )
>   AC_SUBST(SVE_CFLAGS)
> ])
> 
> 
> [default.log](https://github.com/user-attachments/files/22293047/default.log)

That's a valid reason not to do it. Seems like there is some issue with nesting calls to our named parameter macros.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344215834

From fandreuzzi at openjdk.org  Fri Sep 12 13:35:12 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 12 Sep 2025 13:35:12 GMT
Subject: RFR: 8367546: Clarify meaning of "corresponding header" for
 architecture-qualified .inline.hpp files
Message-ID: <5CObrpoaAu3vff-Xv8k3o_s-5bBoKU5Y3Rd2BsBapXE=.c806157f-bea6-47b1-b50c-3a60c89b3d93@github.com>

During the review of #27189 we stumbled on the lack of a clear indication of what constitutes the `corresponding .hpp` file for a `.inline.hpp` file having an architecture qualifier.

For example, `continuationHelper_x86.inline.hpp` includes `runtime/continuationHelper.hpp`, and the include statement is on top as stated in the style guide:


#ifndef CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP
#define CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP

#include "runtime/continuationHelper.hpp"

#include "runtime/continuationEntry.inline.hpp"
#include "runtime/frame.inline.hpp"
#include "runtime/registerMap.hpp"
[...]


However, this order is not respected by `SortIncludes.java`, which does not designate `runtime/continuationHelper.hpp` as the "corresponding `.hpp` file". If this concept was clarified in the style guide, we could improve `SortIncludes` accordingly.

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

Commit messages:
 - change guide

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

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

From syan at openjdk.org  Fri Sep 12 13:44:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 13:44:04 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

 - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
 - Use CC directly
 - Move comment from called to macro definition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/350ac24d..579c9c3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=16-17

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

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

From syan at openjdk.org  Fri Sep 12 13:50:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 13:50:15 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v17]
In-Reply-To: <GvzwL9j2N5-1DFFMHXLbeKjMG88LvjoXfm5ajWH3sS0=.c0540742-09ad-4b82-a27d-1d1107759d68@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <pPdoMDNLgfZjBDA0gI3kDBe_BFgjTTsvWBejxVkqfMU=.6de57e3e-3dd0-43d3-85ff-d7a3ea584bba@github.com>
 <GvzwL9j2N5-1DFFMHXLbeKjMG88LvjoXfm5ajWH3sS0=.c0540742-09ad-4b82-a27d-1d1107759d68@github.com>
Message-ID: <Hrhg-seOzuD5YHaCMb9oagw2E7cJE4xJ82qzUY70THc=.3e891f30-7273-456c-8c0f-22574425dbd0@github.com>

On Fri, 12 Sep 2025 13:03:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary CFLAGS save and restore
>
> make/autoconf/flags-other.m4 line 128:
> 
>> 126:           saved_cc="$CC"
>> 127:           CFLAGS="$CFLAGS -march=armv8-a+sve $CFLAGS_WARNINGS_ARE_ERRORS ARG_ARGUMENT"
>> 128:           CC="$ARG_PREFIX[CC]"
> 
> You shouldn't need to save `CC` and use a custom one here. `CC` should be the target compiler already.

Thanks for the correction. The unnecessary ARG_PREFIX has been removed.

> make/autoconf/flags-other.m4 line 140:
> 
>> 138:             [AVAILABLE=false]
>> 139:           )
>> 140:           AC_MSG_RESULT([$AVAILABLE])
> 
> This will now print true/false instead of yes/no, which will look a bit weird. It's a consequence of us preferring `true/false` to express booleans internally. I think I would inline the call to `AC_MSG_RESULT` in each of the branches of `AC_COMPILE_IFELSE` to work around this.

Okey, the `AC_MSG_RESULT` call has been moved to the branches of `AC_COMPILE_IFELSE`.

> make/autoconf/flags.m4 line 380:
> 
>> 378:   # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
>> 379:   # ACLE and this flag are required to build the aarch64 SVE related functions
>> 380:   # in libvectormath.
> 
> I think you misunderstood me here, I meant move it to the top of the macro declaration, not the call. I think it makes more sense to document it where it's defined.

Sorry for the misunderstood. The comment has been moved to the top of macro,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344310975
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344321261
PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344306576

From erikj at openjdk.org  Fri Sep 12 13:50:19 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Sep 2025 13:50:19 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
Message-ID: <urpEMg1v4fE0dtyp2WGZazMKdWCcA3m65qEjkg-d1Q8=.2ed71224-6a77-433e-bf6f-c480faa456f1@github.com>

On Fri, 12 Sep 2025 13:44:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
>  - Use CC directly
>  - Move comment from called to macro definition

make/autoconf/flags-other.m4 line 139:

> 137:             [
> 138:               AVAILABLE=true
> 139:               AC_MSG_RESULT([$AVAILABLE])

I meant that you would explicitly output `yes` here, otherwise there is no point in moving the call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344318327

From syan at openjdk.org  Fri Sep 12 13:55:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 13:55:19 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <urpEMg1v4fE0dtyp2WGZazMKdWCcA3m65qEjkg-d1Q8=.2ed71224-6a77-433e-bf6f-c480faa456f1@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
 <urpEMg1v4fE0dtyp2WGZazMKdWCcA3m65qEjkg-d1Q8=.2ed71224-6a77-433e-bf6f-c480faa456f1@github.com>
Message-ID: <Et8Iz-f7RIann46zOw6hHaNgOm_qZ1x_c7heYLklTAY=.d20feb51-650d-4151-b515-7d3b40f95c14@github.com>

On Fri, 12 Sep 2025 13:47:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
>>  - Use CC directly
>>  - Move comment from called to macro definition
>
> make/autoconf/flags-other.m4 line 139:
> 
>> 137:             [
>> 138:               AVAILABLE=true
>> 139:               AC_MSG_RESULT([$AVAILABLE])
> 
> I meant that you would explicitly output `yes` here, otherwise there is no point in moving the call.

Got it now. I think I need improve my English..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344333705

From syan at openjdk.org  Fri Sep 12 14:06:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 12 Sep 2025 14:06:15 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
Message-ID: <qcgHWdBjjQpQsyQ-V4JttWoIsCJ6h7_qTNVzROdJUK0=.df17f683-e281-463f-9d4d-56d3d96503f8@github.com>

On Fri, 12 Sep 2025 13:44:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
>  - Use CC directly
>  - Move comment from called to macro definition

Tested:

- [x] 1. linux-aarch64 gcc-10 as-2.37, inlcude release build and fastdebug build
- [x] 2. linux-aarch64 gcc-10 as-2.30
- [x] 3. linux-aarch64 gcc-12 as-2.38, inlcude release build and fastdebug build
- [x] 4. linux-x64

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3285420885

From ihse at openjdk.org  Fri Sep 12 14:53:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 12 Sep 2025 14:53:56 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
Message-ID: <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>

On Fri, 12 Sep 2025 13:44:04 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
>  - Use CC directly
>  - Move comment from called to macro definition

make/autoconf/flags-other.m4 line 120:

> 118:     DESC: [Use SVE when compiling libsleef],
> 119:     AVAILABLE: false,
> 120:     CHECK_AVAILABLE: [

You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.

Instead I suggest the following:
Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).

Then, finally, you can do like this:

 UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
    RESULT: AARCH64_SVE_ENABLED,
    DESC: [Use SVE when compiling libsleef],
    AVAILABLE: $AARCH64_SVE_AVAILABLE)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344488195

From ihse at openjdk.org  Fri Sep 12 14:53:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 12 Sep 2025 14:53:58 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
 <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>
Message-ID: <qJUHtZt1bjzqGm4JZS5usVL4FlkWzZKjqkCj-Z8vDzQ=.90304144-7ffb-4579-9bad-1d3dfb707e2e@github.com>

On Fri, 12 Sep 2025 14:49:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Call AC_MSG_RESULT([$AVAILABLE]) inside AC_COMPILE_IFELSE
>>  - Use CC directly
>>  - Move comment from called to macro definition
>
> make/autoconf/flags-other.m4 line 120:
> 
>> 118:     DESC: [Use SVE when compiling libsleef],
>> 119:     AVAILABLE: false,
>> 120:     CHECK_AVAILABLE: [
> 
> You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.
> 
> Instead I suggest the following:
> Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).
> 
> Then, finally, you can do like this:
> 
>  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>     RESULT: AARCH64_SVE_ENABLED,
>     DESC: [Use SVE when compiling libsleef],
>     AVAILABLE: $AARCH64_SVE_AVAILABLE)

Oh, and also, you can extract a common:

AC_MSG_RESULT([$AARCH64_SVE_AVAILABLE])

after the compile test. This lets you get rid of the else block completely, and it makes it clear that the AC_MSG_CHECKING is always terminated. (Apart from being shorter)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344492786

From erikj at openjdk.org  Fri Sep 12 16:33:24 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Sep 2025 16:33:24 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <qJUHtZt1bjzqGm4JZS5usVL4FlkWzZKjqkCj-Z8vDzQ=.90304144-7ffb-4579-9bad-1d3dfb707e2e@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
 <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>
 <qJUHtZt1bjzqGm4JZS5usVL4FlkWzZKjqkCj-Z8vDzQ=.90304144-7ffb-4579-9bad-1d3dfb707e2e@github.com>
Message-ID: <2lAsgWzWkILWxIUXfWhJNXDC3zXp3WPdpCGKLNokP18=.98d31676-25d2-471f-9494-e0027dc59e71@github.com>

On Fri, 12 Sep 2025 14:51:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-other.m4 line 120:
>> 
>>> 118:     DESC: [Use SVE when compiling libsleef],
>>> 119:     AVAILABLE: false,
>>> 120:     CHECK_AVAILABLE: [
>> 
>> You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.
>> 
>> Instead I suggest the following:
>> Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).
>> 
>> Then, finally, you can do like this:
>> 
>>  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>>     RESULT: AARCH64_SVE_ENABLED,
>>     DESC: [Use SVE when compiling libsleef],
>>     AVAILABLE: $AARCH64_SVE_AVAILABLE)
>
> Oh, and also, you can extract a common:
> 
> AC_MSG_RESULT([$AARCH64_SVE_AVAILABLE])
> 
> after the compile test. This lets you get rid of the else block completely, and it makes it clear that the AC_MSG_CHECKING is always terminated. (Apart from being shorter)

> You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.
> 
> Instead I suggest the following: Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).
> 
> Then, finally, you can do like this:
> 
> ```
>  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>     RESULT: AARCH64_SVE_ENABLED,
>     DESC: [Use SVE when compiling libsleef],
>     AVAILABLE: $AARCH64_SVE_AVAILABLE)
> ```

Here is the code evaluating AVAILABLE:


  # Check if the option is available
  AVAILABLE=ARG_AVAILABLE
  # Run the available check block (if any), which can overwrite AVAILABLE.
  ARG_CHECK_AVAILABLE

Which is why I interpreted it as ok to supply both AVAILABLE as a default and AVAILABLE_CHECK.

Also I don't agree that this is too big to be inline. I think it's perfectly readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344815625

From erikj at openjdk.org  Fri Sep 12 16:33:25 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Sep 2025 16:33:25 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <2lAsgWzWkILWxIUXfWhJNXDC3zXp3WPdpCGKLNokP18=.98d31676-25d2-471f-9494-e0027dc59e71@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
 <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>
 <qJUHtZt1bjzqGm4JZS5usVL4FlkWzZKjqkCj-Z8vDzQ=.90304144-7ffb-4579-9bad-1d3dfb707e2e@github.com>
 <2lAsgWzWkILWxIUXfWhJNXDC3zXp3WPdpCGKLNokP18=.98d31676-25d2-471f-9494-e0027dc59e71@github.com>
Message-ID: <Gpgrnw5wNx1D7iSgR4ZiMoOiW9VB9g_dvPxR6Q2cXJE=.bdf19697-b731-4cdb-965b-c645d9734e6b@github.com>

On Fri, 12 Sep 2025 16:28:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Oh, and also, you can extract a common:
>> 
>> AC_MSG_RESULT([$AARCH64_SVE_AVAILABLE])
>> 
>> after the compile test. This lets you get rid of the else block completely, and it makes it clear that the AC_MSG_CHECKING is always terminated. (Apart from being shorter)
>
>> You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.
>> 
>> Instead I suggest the following: Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).
>> 
>> Then, finally, you can do like this:
>> 
>> ```
>>  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>>     RESULT: AARCH64_SVE_ENABLED,
>>     DESC: [Use SVE when compiling libsleef],
>>     AVAILABLE: $AARCH64_SVE_AVAILABLE)
>> ```
> 
> Here is the code evaluating AVAILABLE:
> 
> 
>   # Check if the option is available
>   AVAILABLE=ARG_AVAILABLE
>   # Run the available check block (if any), which can overwrite AVAILABLE.
>   ARG_CHECK_AVAILABLE
> 
> Which is why I interpreted it as ok to supply both AVAILABLE as a default and AVAILABLE_CHECK.
> 
> Also I don't agree that this is too big to be inline. I think it's perfectly readable.

The issue with using the AVAILABLE variable in `AC_MSG_RESULT` is that it has the values true/false not yes/no, which is the common output for results of configure tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2344827094

From syan at openjdk.org  Sun Sep 14 13:03:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 14 Sep 2025 13:03:57 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v19]
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <dgQcv4evJW6O49EzvsjqMuZxvck9Am_LrXZbt81C1kw=.03cdb192-2a28-45cd-aac7-b8a57f8c9310@github.com>

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

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

 - Remove CHECK_AVAILABLE from UTIL_ARG_ENABLE
 - AC_MSG_RESULT yes/no instead of $AVAILABLE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27073/files
  - new: https://git.openjdk.org/jdk/pull/27073/files/579c9c3e..ea399f55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27073&range=17-18

  Stats: 59 lines in 1 file changed: 27 ins; 31 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27073/head:pull/27073

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

From syan at openjdk.org  Sun Sep 14 13:15:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 14 Sep 2025 13:15:15 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v18]
In-Reply-To: <Gpgrnw5wNx1D7iSgR4ZiMoOiW9VB9g_dvPxR6Q2cXJE=.bdf19697-b731-4cdb-965b-c645d9734e6b@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <hIwj9GTI4ixJJCpSaMbY_-BheJPBXpD1igrVT9405IA=.b0c0e90c-a995-490a-a7a1-371a959f82e6@github.com>
 <kNkTBrVR_MxnTteK7uyDPI7tGflskjZa2ukd-2knX4s=.31a9d46c-19fc-4dc6-9b4d-809651363d65@github.com>
 <qJUHtZt1bjzqGm4JZS5usVL4FlkWzZKjqkCj-Z8vDzQ=.90304144-7ffb-4579-9bad-1d3dfb707e2e@github.com>
 <2lAsgWzWkILWxIUXfWhJNXDC3zXp3WPdpCGKLNokP18=.98d31676-25d2-471f-9494-e0027dc59e71@github.com>
 <Gpgrnw5wNx1D7iSgR4ZiMoOiW9VB9g_dvPxR6Q2cXJE=.bdf19697-b731-4cdb-965b-c645d9734e6b@github.com>
Message-ID: <xlymMJAin_3lp43HVjTI3M2ptt01fGuUlMKjaHx-yT8=.2ea826fd-249f-4e91-91df-e49cf971fc80@github.com>

On Fri, 12 Sep 2025 16:30:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> You are not supposed to both provide AVAILABLE and CHECK_AVAILABLE. Also, if you do setup CHECK_AVAILABLE you should always provide a value to the AVAILABLE variable; now you don't have an else clause for the cpu and toolchain tests. Also, CHECK_AVAILABLE was designed for small and simple tests; this is so long it becames hard to read.
>>> 
>>> Instead I suggest the following: Start by setting AARCH64_SVE_AVAILABLE to false. Then do the code that is currently in the CHECK_AVAILABLE block, but replace the assignment to AVAILABLE with an assignment to AARCH64_SVE_AVAILABLE. (Where it is true, since you defaulted it to false you can skip that line).
>>> 
>>> Then, finally, you can do like this:
>>> 
>>> ```
>>>  UTIL_ARG_ENABLE(NAME: aarch64-sve, DEFAULT: auto,
>>>     RESULT: AARCH64_SVE_ENABLED,
>>>     DESC: [Use SVE when compiling libsleef],
>>>     AVAILABLE: $AARCH64_SVE_AVAILABLE)
>>> ```
>> 
>> Here is the code evaluating AVAILABLE:
>> 
>> 
>>   # Check if the option is available
>>   AVAILABLE=ARG_AVAILABLE
>>   # Run the available check block (if any), which can overwrite AVAILABLE.
>>   ARG_CHECK_AVAILABLE
>> 
>> Which is why I interpreted it as ok to supply both AVAILABLE as a default and AVAILABLE_CHECK.
>> 
>> Also I don't agree that this is too big to be inline. I think it's perfectly readable.
>
> The issue with using the AVAILABLE variable in `AC_MSG_RESULT` is that it has the values true/false not yes/no, which is the common output for results of configure tests.

Thanks. CHECK_AVAILABLE has been removed from UTIL_ARG_ENABLE, I think this will make the usage of UTIL_ARG_ENABLE looks more consistent with other makefiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27073#discussion_r2347321246

From alanb at openjdk.org  Mon Sep 15 16:40:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Sep 2025 16:40:09 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <VcYSJAsXqXkCnXDHTRSe2Gwt92aDdsljMAject_0A7M=.a4ff1f12-47e9-40dc-97d4-061ebd5271c0@github.com>
Message-ID: <xOfXXkHET1mY9vC6f57zKsjsaIfsbq6ghbvTvO-F6a0=.653777df-9083-469f-9027-66657b60689f@github.com>

On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. 
> 
> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run.

> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this.

I think it's okay, and good for testing. I went through the relauncher closely, just not 100% sure of the quoting in the Windows implementation so I'm hoping Roger will have a few mins to scan that function.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3293033509

From alanb at openjdk.org  Mon Sep 15 16:40:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Sep 2025 16:40:11 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
Message-ID: <FhLPma67skb7m-y2WkyqaOSpS5pIDsSAAXIlbTOSM3k=.9e3d1659-1f4e-4eaf-95ea-ee9335873cbd@github.com>

On Thu, 11 Sep 2025 12:13:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug code

src/java.base/windows/native/launcher/relauncher.c line 40:

> 38: static char* launcher_args[] = LAUNCHER_ARGS;
> 39: 
> 40: char* quote_argument(char* arg) {

@RogerRiggs Would you mind scanning the quote_argument in the Windows launcher? You've had to deal with this in the process code and I think good to get another set of eyes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349554917

From rriggs at openjdk.org  Mon Sep 15 17:33:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Sep 2025 17:33:26 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <FhLPma67skb7m-y2WkyqaOSpS5pIDsSAAXIlbTOSM3k=.9e3d1659-1f4e-4eaf-95ea-ee9335873cbd@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <FhLPma67skb7m-y2WkyqaOSpS5pIDsSAAXIlbTOSM3k=.9e3d1659-1f4e-4eaf-95ea-ee9335873cbd@github.com>
Message-ID: <mUBQ04dYb_BtZCsf-YeMlqbubaIIfjMH8GpLnfpenaM=.bdbe969a-f268-4da8-bf86-fe0630bc8fe4@github.com>

On Mon, 15 Sep 2025 16:35:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug code
>
> src/java.base/windows/native/launcher/relauncher.c line 40:
> 
>> 38: static char* launcher_args[] = LAUNCHER_ARGS;
>> 39: 
>> 40: char* quote_argument(char* arg) {
> 
> @RogerRiggs Would you mind scanning the quote_argument in the Windows launcher? You've had to deal with this in the process code and I think good to get another set of eyes.

Looks looks good.  The algorithm in the windows version of ProcessImpl.java is the almost the same but the implementation is slightly different.  But the result is the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349634869

From rriggs at openjdk.org  Mon Sep 15 17:33:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Sep 2025 17:33:30 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
Message-ID: <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>

On Thu, 11 Sep 2025 12:13:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
>> 
>> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug code

src/java.base/windows/native/launcher/relauncher.c line 79:

> 77:             backslashes = 0;
> 78:         } else {
> 79:             // Backslashes not preceeding a quote is copied without escaping

is -> are

src/java.base/windows/native/launcher/relauncher.c line 153:

> 151:     }
> 152: 
> 153:     // Our executable name (should not be quoted)

ok here, because the full path is being explicitly passed to CreateProcess.
If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted.  It would be good to have a test case with a space in the executable path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349635960
PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349667061

From erikj at openjdk.org  Mon Sep 15 17:40:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 15 Sep 2025 17:40:45 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v19]
In-Reply-To: <dgQcv4evJW6O49EzvsjqMuZxvck9Am_LrXZbt81C1kw=.03cdb192-2a28-45cd-aac7-b8a57f8c9310@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <dgQcv4evJW6O49EzvsjqMuZxvck9Am_LrXZbt81C1kw=.03cdb192-2a28-45cd-aac7-b8a57f8c9310@github.com>
Message-ID: <F9KcxbY2-ckY-Q9zWS-vzBG2tBWgjpawwe7krNLGslA=.fd5b8c7a-b368-44e8-8258-b95dcf351e65@github.com>

On Sun, 14 Sep 2025 13:03:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove CHECK_AVAILABLE from UTIL_ARG_ENABLE
>  - AC_MSG_RESULT yes/no instead of $AVAILABLE

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3225657432

From kbarrett at openjdk.org  Mon Sep 15 23:50:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 15 Sep 2025 23:50:11 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <Rx-8oX6I-55lWCDpFCF2TPHd8e-DevaPhL6XWDNh9EM=.68795033-c1f5-4e5c-833f-c41f391851fe@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

Anyone else have an opinion? @vnkozlov ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3294357127

From kvn at openjdk.org  Tue Sep 16 00:08:18 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Sep 2025 00:08:18 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <xFU6qx49GEZXRs8u7ac44m52wVTteAEv5Y_L0FTvPsw=.0db86916-050b-46e1-8592-0af019c607b7@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

Approved.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3226653895

From acobbs at openjdk.org  Tue Sep 16 01:49:39 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Sep 2025 01:49:39 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression
Message-ID: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>

This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.

Summary of code changes:

* Add new warning and associated lint category `"suppression"`
* Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
* Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
* Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
* Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
* Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break

? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

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

Commit messages:
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - Minor regression test cleanups.
 - Minor comment tweaks.
 - ... and 120 more: https://git.openjdk.org/jdk/compare/11cdafb8...e3283ba9

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344159
  Stats: 1661 lines in 33 files changed: 1485 ins; 51 del; 125 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From kbarrett at openjdk.org  Tue Sep 16 04:45:23 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Sep 2025 04:45:23 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <9hUH1qBRX4d6CXWWmL2f0JXpjNcL4T82CruLjH-5954=.05957ee0-33b7-4be9-8d39-5068d46bf9f9@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

Thanks for reviews and approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3295110649

From kbarrett at openjdk.org  Tue Sep 16 04:45:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Sep 2025 04:45:24 GMT
Subject: Integrated: 8252582: HotSpot Style Guide should permit variable
 templates
In-Reply-To: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
Message-ID: <fm0Wd4lwY6lG3njj8E-uJPbEVinhdSpsWFOMfGUrTIo=.55992043-bc6c-4dad-9c2f-75145e134867@github.com>

On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to permit the use of
> variable templates. This is a C++14 feature that, while fairly simple, didn't
> get into the initial permitted for HotSpot list because I just didn't get to
> it and nobody asked for it. And it has languished on the "undecided" list for
> the same reasons. But recently I've had reason to want to use this feature a
> couple of times, so I'm now proposing we allow it.
> 
> I merged it into the section for Inline Variables (a C++17 feature), as the
> two are closely related. Variable templates were even listed as one of the
> workarounds being used to make up for the lack of inline variables.

This pull request has now been integrated.

Changeset: 0fbae805
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fbae8050b6f853053c7dee6a43d3ffbcfa69954
Stats:     50 lines in 2 files changed: 15 ins; 7 del; 28 mod

8252582: HotSpot Style Guide should permit variable templates

Reviewed-by: dholmes, stefank, kvn

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

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

From kbarrett at openjdk.org  Tue Sep 16 05:50:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 16 Sep 2025 05:50:47 GMT
Subject: RFR: 8367724: Remove Trailing Return Types from undecided list
Message-ID: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com>

Please review this trivial editorial change to the HotSpot Style Guide. This
change removes Trailing Return Types from the undecided list. This should have
been done as part of JDK-8366057, but was forgotten.

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

Commit messages:
 - remove trailing return types from undecided list

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

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

From adinn at openjdk.org  Tue Sep 16 12:02:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 16 Sep 2025 12:02:59 GMT
Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates
In-Reply-To: <Rx-8oX6I-55lWCDpFCF2TPHd8e-DevaPhL6XWDNh9EM=.68795033-c1f5-4e5c-833f-c41f391851fe@github.com>
References: <dCclv3u4G6AGFvSXwXssXrivOMwJ1g5LR9v9ICzA7YY=.944e70f1-43da-4605-9540-18b98f7f3aed@github.com>
 <Rx-8oX6I-55lWCDpFCF2TPHd8e-DevaPhL6XWDNh9EM=.68795033-c1f5-4e5c-833f-c41f391851fe@github.com>
Message-ID: <I99PwBwgljvME8F7yTjJs_LxKdMZTXK3tveEhfDsp6I=.8e6962d2-2288-473c-860f-dfc24a083ed5@github.com>

On Mon, 15 Sep 2025 23:47:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Anyone else have an opinion?

Sorry I am too late to review the PR but I did read the proposal and wish to record approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3298236460

From erikj at openjdk.org  Tue Sep 16 13:04:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Sep 2025 13:04:16 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <w_bendDhRUOHS9-TqRVVwj2ewL3Ye80CAM308VR98qc=.3428049b-bcf7-486a-9046-743ff8829fc3@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3229887954

From erikj at openjdk.org  Tue Sep 16 13:55:23 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Sep 2025 13:55:23 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

> /label remove kulla

I have removed kulla-dev from the bot configuration so the stuck label is now benign.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3298796516

From darcy at openjdk.org  Tue Sep 16 19:01:10 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Sep 2025 19:01:10 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3299975129

From acobbs at openjdk.org  Tue Sep 16 20:06:30 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Sep 2025 20:06:30 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
Message-ID: <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>

On Tue, 16 Sep 2025 18:58:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?

Hi @jddarcy,

At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)

Here is the list of earlier clean up PR's:

* #22906
* #21859 
* #21858 
* #21857 
* #21856 
* #21855
* #21854 
* #21853 
* #21852 
* #21851
* #21850 
* #21844

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300177821

From darcy at openjdk.org  Tue Sep 16 20:17:03 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Sep 2025 20:17:03 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <MQk_c-8ME3g7aGxh0gBCqXXKL3vY6yafNuDpG2-xpKM=.e0c950f0-eead-4ebe-a208-3db3e5ef0faa@github.com>
 <tpiPsc2LopVOyxCrTiUlPydPgZTXTki_S_fK4WLrnhY=.8989a943-8d89-402e-b2e4-9badfca251ac@github.com>
Message-ID: <OfPvRWmG86FOY9SVCOsuEjJKZthp0ML8Eatq2CZnsmg=.2a8ed59f-b5b5-47ec-b70a-8b4d83353342@github.com>

On Tue, 16 Sep 2025 20:03:45 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
>
>> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
> 
> Hi @jddarcy,
> 
> At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)
> 
> Here is the list of earlier clean up PR's:
> 
> * #22906
> * #21859 
> * #21858 
> * #21857 
> * #21856 
> * #21855
> * #21854 
> * #21853 
> * #21852 
> * #21851
> * #21850 
> * #21844

> > Hi @archiecobbs , are there bugs filed to clean the causes of the warnings?
> 
> Hi @jddarcy,
> 
> At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :)
> 
> Here is the list of earlier clean up PR's:
> 
>     * [8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) #22906](https://github.com/openjdk/jdk/pull/22906)
> 
>     * [8343486: Remove unnecessary @SuppressWarnings annotations and -Xlint:-foo options #21859](https://github.com/openjdk/jdk/pull/21859)
> 
>     * [8343484: Remove unnecessary @SuppressWarnings annotations (nio) #21858](https://github.com/openjdk/jdk/pull/21858)
> 
>     * [8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) #21857](https://github.com/openjdk/jdk/pull/21857)
> 
>     * [8343482: Remove unnecessary @SuppressWarnings annotations (net) #21856](https://github.com/openjdk/jdk/pull/21856)
> 
>     * [8343481: Remove unnecessary @SuppressWarnings annotations (kulla) #21855](https://github.com/openjdk/jdk/pull/21855)
> 
>     * [8343480: Remove unnecessary @SuppressWarnings annotations (javadoc) #21854](https://github.com/openjdk/jdk/pull/21854)
> 
>     * [8343479: Remove unnecessary @SuppressWarnings annotations (hotspot) #21853](https://github.com/openjdk/jdk/pull/21853)
> 
>     * [8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) #21852](https://github.com/openjdk/jdk/pull/21852)
> 
>     * [8343477: Remove unnecessary @SuppressWarnings annotations (compiler) #21851](https://github.com/openjdk/jdk/pull/21851)
> 
>     * [8343476: Remove unnecessary @SuppressWarnings annotations (client) #21850](https://github.com/openjdk/jdk/pull/21850)
> 
>     * [8343467: Remove unnecessary @SuppressWarnings annotations (security) #21844](https://github.com/openjdk/jdk/pull/21844)

Sounds good; I linked the umbrella issue for the earlier round of cleanup to this issue in JBS.

My interest is getting back to at least a subset of modules, including java.base, compiling under "-Xlint:all -Werror" and it sounds like that is the plan as follow-up work after this PR goes in; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300210592

From dholmes at openjdk.org  Wed Sep 17 00:58:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 00:58:38 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v4]
In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com>
Message-ID: <cfVmDKLiYpZIuaO8cwYgRgaD363Uop3jY7bM5B4d8UY=.5ce567df-5131-419c-91dd-97a6d566155c@github.com>

On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

I'm happy to see this go in now. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3300816267

From jpai at openjdk.org  Wed Sep 17 05:29:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Sep 2025 05:29:25 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for ps
 command
Message-ID: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>

Can I please get a review of this trivial change to a jtreg failure handler command?

As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.

The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

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

Commit messages:
 - 8367801: jtreg failure_handler - don't use the -L option for ps command

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

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

From cstein at openjdk.org  Wed Sep 17 05:41:55 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 17 Sep 2025 05:41:55 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Christian Stein 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
 - Update to use correct library directories
   
   See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/12b0d0f5..7f2017b4

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

  Stats: 34669 lines in 1054 files changed: 16580 ins; 9869 del; 8220 mod
  Patch: https://git.openjdk.org/jdk/pull/26261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261

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

From jwaters at openjdk.org  Wed Sep 17 06:24:46 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 17 Sep 2025 06:24:46 GMT
Subject: RFR: 8356379: Need a proper way to test existence of binary from
 configure
In-Reply-To: <JdAqLvj69diQWCvBrXrlCTcuciJUeZDVK0rtqZCouA8=.6fbb3db1-b90f-4862-b306-b9fad39fb91c@github.com>
References: <JdAqLvj69diQWCvBrXrlCTcuciJUeZDVK0rtqZCouA8=.6fbb3db1-b90f-4862-b306-b9fad39fb91c@github.com>
Message-ID: <hE3UczSs5xsNtlUOYGSErHOG3d5jbKB_mqJcf0rHy6A=.ce75b096-11fa-482f-b292-6c8d4f42fa00@github.com>

On Wed, 7 May 2025 10:57:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we setup a command to run, e.g. $FOO we typically set this to just a path to a binary, e.g. /usr/bin/foo. However, this is not necessarily true. On Windows, this can be prefixed by the $FIXPATH prefix, and on all platforms we are allowed to pass arguments to the executable.
> 
> If we want to test if this binary actually exists, we need to extract the binary name from this command line. We have a NOFIXPATH argument to UTIL_LOOKUP_PROGS, which tried to resolve this, but it is not enough, and it makes it impossible to both lookup a program properly and also check for its existance afterwards.
> 
> Instead, I propose to add a UTIL_GET_EXECUTABLE function that extracts just the path to the binary from such a command.

I was using the NOFIXPATH argument downstream since non Microsoft tools don't actually need FIXPATH despite being on Windows :( Oh well, what's done is done, just wish I had caught this back when this was proposed

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

PR Comment: https://git.openjdk.org/jdk/pull/25087#issuecomment-3301481281

From alanb at openjdk.org  Wed Sep 17 06:41:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Sep 2025 06:41:54 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
Message-ID: <m59WFc1Ztj6NJpJY3sElQPqGJI5W5W_4zZ_n3UnnH9w=.fd51b646-ea8a-4db7-927e-6b760c16e076@github.com>

On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

make/autoconf/lib-tests.m4 line 31:

> 29: 
> 30: # Minimum supported versions
> 31: JTREG_MINIMUM_VERSION=8

Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354467094

From cstein at openjdk.org  Wed Sep 17 06:45:37 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 17 Sep 2025 06:45:37 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <m59WFc1Ztj6NJpJY3sElQPqGJI5W5W_4zZ_n3UnnH9w=.fd51b646-ea8a-4db7-927e-6b760c16e076@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
 <m59WFc1Ztj6NJpJY3sElQPqGJI5W5W_4zZ_n3UnnH9w=.fd51b646-ea8a-4db7-927e-6b760c16e076@github.com>
Message-ID: <Gw1O8QfORDA2Dh8oDWY0lb0kk_lSys0O9Xg4D9TU8Ok=.e1a6a06a-673b-4d51-b73e-5431b62a5b9c@github.com>

On Wed, 17 Sep 2025 06:39:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>>  - Update to use correct library directories
>>    
>>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>>  - 8361950: Set required version to 8+2
>>  - 8361950: Update to use jtreg 8
>
> make/autoconf/lib-tests.m4 line 31:
> 
>> 29: 
>> 30: # Minimum supported versions
>> 31: JTREG_MINIMUM_VERSION=8
> 
> Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious).

It's 8. The +2 refers to the build number, which is required in other places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354476356

From alanb at openjdk.org  Wed Sep 17 06:52:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Sep 2025 06:52:34 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <Gw1O8QfORDA2Dh8oDWY0lb0kk_lSys0O9Xg4D9TU8Ok=.e1a6a06a-673b-4d51-b73e-5431b62a5b9c@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
 <m59WFc1Ztj6NJpJY3sElQPqGJI5W5W_4zZ_n3UnnH9w=.fd51b646-ea8a-4db7-927e-6b760c16e076@github.com>
 <Gw1O8QfORDA2Dh8oDWY0lb0kk_lSys0O9Xg4D9TU8Ok=.e1a6a06a-673b-4d51-b73e-5431b62a5b9c@github.com>
Message-ID: <166qfREU1L7ZkPFg-uAVlnjoiaysBbGxYRRfAGU147E=.ba03b95e-726e-4e31-b05e-e0a2afebcfd6@github.com>

On Wed, 17 Sep 2025 06:43:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> make/autoconf/lib-tests.m4 line 31:
>> 
>>> 29: 
>>> 30: # Minimum supported versions
>>> 31: JTREG_MINIMUM_VERSION=8
>> 
>> Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious).
>
> It's 8. The +2 refers to the build number, which is required in other places.

Thanks for clarifying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354488946

From ayang at openjdk.org  Wed Sep 17 08:39:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 17 Sep 2025 08:39:22 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <yeEyj_hSjcuVDpc-M4CNa64mhWKJAiFuLKBTwqmq0JY=.e65977d4-443c-4d19-95a8-aceea081dcc8@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27328#pullrequestreview-3233323165

From ihse at openjdk.org  Wed Sep 17 08:41:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 08:41:57 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
Message-ID: <S6omoSsR_Mgre6KMz4NPIwJJQ92lSQsXz8gM-8-z6Cw=.9b6be1c6-84e2-4a06-b33a-bb873a255d3b@github.com>

On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3233332473

From ihse at openjdk.org  Wed Sep 17 08:45:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 08:45:24 GMT
Subject: RFR: 8356379: Need a proper way to test existence of binary from
 configure
In-Reply-To: <JdAqLvj69diQWCvBrXrlCTcuciJUeZDVK0rtqZCouA8=.6fbb3db1-b90f-4862-b306-b9fad39fb91c@github.com>
References: <JdAqLvj69diQWCvBrXrlCTcuciJUeZDVK0rtqZCouA8=.6fbb3db1-b90f-4862-b306-b9fad39fb91c@github.com>
Message-ID: <SEG1v40On3SKY3uaUb58mVlcQqk8CnKnN4Dv4RFN2rc=.6558930c-9e19-4994-98f0-aaef17f6fd6a@github.com>

On Wed, 7 May 2025 10:57:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we setup a command to run, e.g. $FOO we typically set this to just a path to a binary, e.g. /usr/bin/foo. However, this is not necessarily true. On Windows, this can be prefixed by the $FIXPATH prefix, and on all platforms we are allowed to pass arguments to the executable.
> 
> If we want to test if this binary actually exists, we need to extract the binary name from this command line. We have a NOFIXPATH argument to UTIL_LOOKUP_PROGS, which tried to resolve this, but it is not enough, and it makes it impossible to both lookup a program properly and also check for its existance afterwards.
> 
> Instead, I propose to add a UTIL_GET_EXECUTABLE function that extracts just the path to the binary from such a command.

What do you mean? We only prepend FIXPATH if the tool in question needs it. How do we know? We check the binary to see if it is a cygwin (or msys, or wsl) binary, or a native windows executable. I don't remember all details, but on Cygwin I know we use ldd to check for dependencies to cygwin*.dll. If it has such a dependency, no FIXPATH is needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25087#issuecomment-3301966148

From ihse at openjdk.org  Wed Sep 17 08:48:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 08:48:22 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v19]
In-Reply-To: <dgQcv4evJW6O49EzvsjqMuZxvck9Am_LrXZbt81C1kw=.03cdb192-2a28-45cd-aac7-b8a57f8c9310@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <dgQcv4evJW6O49EzvsjqMuZxvck9Am_LrXZbt81C1kw=.03cdb192-2a28-45cd-aac7-b8a57f8c9310@github.com>
Message-ID: <7IheawzhrVk1lYX86Ajg-65heTIMt_OmGSap71tGIaQ=.5c143270-9095-4581-96c0-f05f7a7e47c3@github.com>

On Sun, 14 Sep 2025 13:03:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>> 
>> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
>> 
>> Testing:
>> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
>> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
>> 
>> 
>> The compilation fails demo as below:
>> 
>> 
>> # cat sve.c 
>> #include <arm_sve.h>
>> svfloat64_t a() {}
>> # gcc -march=armv8-a+sve sve.c 
>> /tmp/ccVOzMzb.s: Assembler messages:
>> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove CHECK_AVAILABLE from UTIL_ARG_ENABLE
>  - AC_MSG_RESULT yes/no instead of $AVAILABLE

Thank you! Now this looks properly good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27073#pullrequestreview-3233356286

From ihse at openjdk.org  Wed Sep 17 08:51:28 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 08:51:28 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
Message-ID: <OzQZKLtjqyXx5GAiP_737KgSPDJLwI0KfEGQ4LbLroE=.8d84c455-b8a6-42ac-a982-97ae21d048de@github.com>

On Mon, 15 Sep 2025 17:14:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug code
>
> src/java.base/windows/native/launcher/relauncher.c line 79:
> 
>> 77:             backslashes = 0;
>> 78:         } else {
>> 79:             // Backslashes not preceeding a quote is copied without escaping
> 
> is -> are

Thanks. This is my eternal nemesis in English. Why can't you just be like normal people and use the same word independent on numerus?! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2354790932

From shade at openjdk.org  Wed Sep 17 10:05:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 Sep 2025 10:05:48 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <82IHZUHXIAjbljGxX27j7nsc8GUjTOCxNOXmYwiwlw8=.25ba5af1-4199-41cd-b75d-7758d7b51d34@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

How bad is the output with `-L`, really? I would have thought having more debugging info is better for post-mortem diagnostics -- especially if you cannot re-run the test -- even if it is more verbose.

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

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3302256315

From jpai at openjdk.org  Wed Sep 17 10:45:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Sep 2025 10:45:02 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <xnyUngilCwfU05NEUVuArB-OaC57rEHPOJ_laXYRsW0=.572dada1-a145-4ee6-86f7-0c9a0fa5673a@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Hello Aleksey,

> How bad is the output with -L, really?

I checked one recent run which collected this ps output when a test timed out. On that run, the "ps" output had 1638 lines (each representing a process/thread). Out of those 1638 lines, there were only 461 unique processes. The rest of them were entries corresponding to the threads in these processes.

> I would have thought having more debugging info is better for post-mortem diagnostics

It's true that having additional information typically helps analyze the failures better. In this ps output however, the entries belonging to the threads haven't provided us anything unique or informative that may have helped understand the failures/time outs. We do collect a lot more thread specific details through jstack, native thread dumps and various other tools and we have relied on those for anything thread specific.

Of course, this isn't a new thing and has been this way always. The reason why this is coming up now is because we have started seeing a lot more intermittent timeout failures in our CI after the recent timeout factor changes and when investigating those failures, the "ps" output tends to be extremely long with these repeated pids (each one for a different thread).

Having said that, I'll let this PR settle for a couple of days to see if the preference is to let that command stay in its current form.

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

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3302398625

From syan at openjdk.org  Wed Sep 17 11:30:05 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Sep 2025 11:30:05 GMT
Subject: RFR: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64 [v9]
In-Reply-To: <U321nmEqwxhuAIxq1E-cwcZVLhN9ivtrj3TEnyJWoi0=.de3dcbcf-3314-4f8f-b30c-0f6e6d0ec8e4@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
 <8BJ_FFlZ4UCUlJSFkqlNmWjHj1tZjAeWyptIHuzWQqY=.2507555f-a230-4f4b-9df3-244f27655ebc@github.com>
 <U321nmEqwxhuAIxq1E-cwcZVLhN9ivtrj3TEnyJWoi0=.de3dcbcf-3314-4f8f-b30c-0f6e6d0ec8e4@github.com>
Message-ID: <mjlHreis3obOeSEKQhTrhRjQuUxsyUwXrNgGpJYDNq4=.988b1962-c8d1-429f-9d8a-ca0be0a487bb@github.com>

On Wed, 10 Sep 2025 14:02:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Include the prefix argument when calling FLAGS_COMPILER_CHECK_ARGUMENTS
>
> One could also argue that the SVE CFLAGS aren't ever relevant to the build compiler and should be moved out of `FLAGS_SETUP_CFLAGS_CPU_DEP`, and only be performed for the target compiler, which would make the whole thing a lot simpler.

@erikj79 @magicus Thanks for the patient reviews and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27073#issuecomment-3302542864

From syan at openjdk.org  Wed Sep 17 11:30:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Sep 2025 11:30:07 GMT
Subject: Integrated: 8366777: Build fails unknown pseudo-op with old AS on
 linux-aarch64
In-Reply-To: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
References: <qVTGw5Y6TwPws9kftN-aRlQcXA84oRTnzn9lQeLgWd0=.62599657-bcb3-48af-b7c5-0db4d6265032@github.com>
Message-ID: <-XHLl3nUYtD4fOXxVMpvzxNJAhR1gHu1LFfn_492Sm8=.abe7da75-3199-4768-a08a-e55957bfbf9e@github.com>

On Wed, 3 Sep 2025 14:35:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report compilation failre, shows as [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
> 
> This PR add the expression `svfloat64_t a() {}` to makefile which will trigger the compilation during configure stage. After this PR, at configure stage will check the gcc and assember support `-march=armv8-a+sve` or not more comprehensive.
> 
> Testing:
> - [x] On linux-aarch64 gcc12.3.1 as2.37, configure set SVE_CFLAGS as '-march=armv8-a+sve'
> - [x] On linux-aarch64 gcc10.3.0 as2.30, configure set SVE_CFLAGS as empty
> 
> 
> The compilation fails demo as below:
> 
> 
> # cat sve.c 
> #include <arm_sve.h>
> svfloat64_t a() {}
> # gcc -march=armv8-a+sve sve.c 
> /tmp/ccVOzMzb.s: Assembler messages:
> /tmp/ccVOzMzb.s:6: Error: unknown pseudo-op: `.variant_pcs'

This pull request has now been integrated.

Changeset: 4719ed67
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4719ed671a8a8e10b77c4748a0e1ee63c19dfefb
Stats:     99 lines in 3 files changed: 57 ins; 42 del; 0 mod

8366777: Build fails unknown pseudo-op with old AS on linux-aarch64

Reviewed-by: erikj, ihse

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

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

From liach at openjdk.org  Wed Sep 17 11:51:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Sep 2025 11:51:58 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
Message-ID: <xqsRVPaFh6Sz8QkVCS3xwIm1MhPo3ixYjydvTTztoRg=.2f05b4a6-3a35-4df8-8b32-c073829a19a1@github.com>

On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3234055339

From matthias.baesken at sap.com  Wed Sep 17 13:41:19 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 17 Sep 2025 13:41:19 +0000
Subject: "useless" librt.so.1  dependency on Linux  reported by dpkg-shlibdeps
Message-ID: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi , when building Debian packages for 25 ,     a couple of messages  complaining about  ?useless?  dependencies  show up .

One is about   libjvm.so depending on   librt.so.1     :

dpkg-shlibdeps: warning: package could avoid a useless dependency if
/usr/lib/jvm/jdk-25/lib/server/libjvm.so
were not linked against librt.so.1 (they use none of the library's symbols)


Looks like in old days, on old distros, this dependency was (maybe?) still useful   :

See  make/autoconf/libraries.m4  :

139   # librt for legacy clock_gettime
140   if test "x$OPENJDK_TARGET_OS" = xlinux; then
141     # Hotspot needs to link librt to get the clock_* functions.
142     # But once our supported minimum build and runtime platform
143     # has glibc 2.17, this can be removed as the functions are
144     # in libc.
145     BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
146   fi


( seems some versions of  RHEL 7  / SLES 12  still had those old glibc versions)


Could we clean this up?
Or is there still some need  to  support this in jdk26  ?


Best regards, Matthias





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250917/fc5b9282/attachment-0001.htm>

From ihse at openjdk.org  Wed Sep 17 14:49:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 14:49:00 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v10]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <XYyXqAYXrvlOaH1eefIzrrqMokx5mIS9Q4q_aR0qYxA=.96d6f935-4b12-4bce-888d-89bff4cd1b45@github.com>

> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present.
> 
> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24380/files
  - new: https://git.openjdk.org/jdk/pull/24380/files/e9925dab..5a554a55

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

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

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

From ihse at openjdk.org  Wed Sep 17 14:54:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 14:54:21 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
Message-ID: <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>

On Mon, 15 Sep 2025 17:29:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug code
>
> src/java.base/windows/native/launcher/relauncher.c line 153:
> 
>> 151:     }
>> 152: 
>> 153:     // Our executable name (should not be quoted)
> 
> ok here, because the full path is being explicitly passed to CreateProcess.
> If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted.  It would be good to have a test case with a space in the executable path.

Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2355810340

From ihse at openjdk.org  Wed Sep 17 15:14:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 15:14:16 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
Message-ID: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>

The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

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

Commit messages:
 - Escape # in literals with \
 - 8367859: Remove shell script from nio exception gensrc

Changes: https://git.openjdk.org/jdk/pull/27338/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367859
  Stats: 1058 lines in 11 files changed: 531 ins; 525 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27338/head:pull/27338

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

From ihse at openjdk.org  Wed Sep 17 15:14:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 15:14:16 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
Message-ID: <LPAeQUcP1uHPBHjMdrl5J3J1qoC5Rg792KpuNagGQOo=.90cb2431-d023-4374-a47f-d6d9c9f0816c@github.com>

On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

Some implementation notes:

I considered writing a Java buildtool to read the existing `exceptions` files, but that seemed like a lot of work to keep up with a format that was not really ideal anyway, but was in fact a shell script snippet, disguised as a data file.

The `*.java.template` method aligns better with most other gensrc solutions. This also makes it easier to get a better understanding of how the resulting file will look. As a matter of fact, the generated file with the old solution did not match up with how our files should look. I modified the template to follow this pattern. As an effect of this, all generated files has a diff (in whitespace or comments only) with this code compared to the old, like this:


--- ReadOnlyBufferException.java        2025-09-11 11:55:45
+++ NEW/ReadOnlyBufferException.java    2025-09-12 17:40:57
@@ -1,6 +1,5 @@
 /*
- * Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved.
- *
+ * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -22,14 +21,10 @@
  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  * or visit www.oracle.com if you need additional information or have any
  * questions.
- *
  */

-// -- This file was mechanically generated: Do not edit! -- //
-
 package java.nio;

-
 /**
  * Unchecked exception thrown when a content-mutation method such as
  * <code>put</code> or <code>compact</code> is invoked upon a read-only buffer.
@@ -48,5 +43,4 @@
      * Constructs an instance of this class.
      */
     public ReadOnlyBufferException() { }
-
 }


I consider this an improvement, not a bug.

I also discovered a real bug. Due to how the old `exceptions` files were actually shell script snippets that were included and executed, proper care needed to be taken in how to handle quotes. This was not done for `IllegalCharsetNameException.java`. The `"` were eaten by the shell, so the generated Java code was:

 * <a href=Charset.html#names>legal charset name</a> is used as such.

instead of (the intended, and correct)

 * <a href="Charset.html#names">legal charset name</a> is used as such.


That is fixed with this PR. 

Apart from these changes, the generated files are identical before and after this PR.

I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302348906
PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302581306

From ihse at openjdk.org  Wed Sep 17 15:14:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 15:14:18 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <LPAeQUcP1uHPBHjMdrl5J3J1qoC5Rg792KpuNagGQOo=.90cb2431-d023-4374-a47f-d6d9c9f0816c@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
 <LPAeQUcP1uHPBHjMdrl5J3J1qoC5Rg792KpuNagGQOo=.90cb2431-d023-4374-a47f-d6d9c9f0816c@github.com>
Message-ID: <7DZVTx-SNw-JWW4PdDlvpTSU0N7G5E5PKNcoXKYC-Nk=.d6675fe3-c6ce-4e40-85cc-2dedcf9a5cee@github.com>

On Wed, 17 Sep 2025 11:36:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system.

The answer to that is "GNU Make 4.3 is going on". I have a tentative fix...

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302785629

From asemenyuk at openjdk.org  Wed Sep 17 15:26:28 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 17 Sep 2025 15:26:28 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
 <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>
Message-ID: <CG1WmHtAaz2_X7JcBhP6jWYy3hkJi-p3sB5NDL1r8nc=.65bc7235-3055-4a3c-8c30-2ca19d3aad8e@github.com>

On Wed, 17 Sep 2025 14:51:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/windows/native/launcher/relauncher.c line 153:
>> 
>>> 151:     }
>>> 152: 
>>> 153:     // Our executable name (should not be quoted)
>> 
>> ok here, because the full path is being explicitly passed to CreateProcess.
>> If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted.  It would be good to have a test case with a space in the executable path.
>
> Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same.

Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly.

You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2355902250

From alanb at openjdk.org  Wed Sep 17 15:28:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Sep 2025 15:28:24 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
Message-ID: <b44igbeyKvVtWIRL13bqAcHjImCXp4yREWa0-X4Ohis=.0315a222-4f4b-4258-80f4-87ce9301f9a6@github.com>

On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

I really dislike this.  Can you please look at putting a template in java.nio.channels and java.nio.charsets for the exceptions in those packages? There will be a naming discussion to have on this too. Same thing for CharsetNameExceptions.java.template.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303528178

From ihse at openjdk.org  Wed Sep 17 15:58:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 15:58:21 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
Message-ID: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>

If the command line changes, it is reason to re-run the command.

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

Commit messages:
 - 8366899: SetupExecute should add the command line to vardeps

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

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

From naoto at openjdk.org  Wed Sep 17 16:05:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Sep 2025 16:05:04 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <b44igbeyKvVtWIRL13bqAcHjImCXp4yREWa0-X4Ohis=.0315a222-4f4b-4258-80f4-87ce9301f9a6@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
 <b44igbeyKvVtWIRL13bqAcHjImCXp4yREWa0-X4Ohis=.0315a222-4f4b-4258-80f4-87ce9301f9a6@github.com>
Message-ID: <xAoag4ATH0zmnClgZ9hKu4t3D1JgXNpXjTIrOAEp-T0=.be18279a-dfe2-4a16-8ea4-1605aa9ed16e@github.com>

On Wed, 17 Sep 2025 15:25:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this?

I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303661328

From alanb at openjdk.org  Wed Sep 17 18:05:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Sep 2025 18:05:03 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
Message-ID: <keCPUixupg6j0s4k7vyvByFZSgiO35Cq5GFstWGeufE=.fda33764-df7c-47fd-8190-1fe1d50824ea@github.com>

On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein 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 six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - Update to use correct library directories
>    
>    See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

I assume you'll do another run of all tiers before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3235634542

From ihse at openjdk.org  Wed Sep 17 18:42:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 18:42:01 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
Message-ID: <Co7dPQXWV2syntudoPBP8Zdxt88zTvF8_W06qnAmGMQ=.0a5b0fc9-22ba-40be-87e3-de1463d02370@github.com>

On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

I'm glad to hear you say that. That was my initial thinking also, but since it was not done that way originally, I thought it would not be acceptable. I think that is a much better solution. I'll create a new PR with checked-in code, but I'll keep this open for the time being, if it turns out a generated solution is preferred.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304151588

From ihse at openjdk.org  Wed Sep 17 19:00:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 19:00:55 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
Message-ID: <QfhlyCP5piaVduZhFVnFhriwxT_ZRDe7ib1qL4334Lk=.7c649f37-c5bb-4ea0-b448-3c6b5679ba8e@github.com>

On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

See https://github.com/openjdk/jdk/pull/27352.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304203859

From ihse at openjdk.org  Wed Sep 17 19:06:50 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 19:06:50 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <CG1WmHtAaz2_X7JcBhP6jWYy3hkJi-p3sB5NDL1r8nc=.65bc7235-3055-4a3c-8c30-2ca19d3aad8e@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
 <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>
 <CG1WmHtAaz2_X7JcBhP6jWYy3hkJi-p3sB5NDL1r8nc=.65bc7235-3055-4a3c-8c30-2ca19d3aad8e@github.com>
Message-ID: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com>

On Wed, 17 Sep 2025 15:23:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same.
>
> Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly.
> 
> You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way.

Yes, I've read that blog post, tried to implement it and credited in the source code. :-)

The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it.

But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356490736

From cstein at openjdk.org  Wed Sep 17 19:24:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 17 Sep 2025 19:24:13 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v5]
In-Reply-To: <keCPUixupg6j0s4k7vyvByFZSgiO35Cq5GFstWGeufE=.fda33764-df7c-47fd-8190-1fe1d50824ea@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <NKpsG0mtp5HkRomNK6-1Gnwucw6Phr1V7Dl8yNxzasg=.06bce144-fc3d-426c-afb7-af95e55dc913@github.com>
 <keCPUixupg6j0s4k7vyvByFZSgiO35Cq5GFstWGeufE=.fda33764-df7c-47fd-8190-1fe1d50824ea@github.com>
Message-ID: <cV2MHakPYnVJvfEapK7f-VgMvVFcy2coS4NXRTT8TP8=.b9b43f57-e60b-405c-9c85-75423727ba1e@github.com>

On Wed, 17 Sep 2025 18:02:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll do another run of all tiers before integrating.

Yes. A run of tier 1-9 is in progress, with tier 1-5 already looking very promising.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3304276125

From asemenyuk at openjdk.org  Wed Sep 17 19:31:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 17 Sep 2025 19:31:10 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
 <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>
 <CG1WmHtAaz2_X7JcBhP6jWYy3hkJi-p3sB5NDL1r8nc=.65bc7235-3055-4a3c-8c30-2ca19d3aad8e@github.com>
 <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com>
Message-ID: <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com>

On Wed, 17 Sep 2025 19:04:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly.
>> 
>> You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way.
>
> Yes, I've read that blog post, tried to implement it and credited in the source code. :-)
> 
> The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it.
> 
> But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way.

Oh, my bad :) I didn't dive into the source code. I came across this discussion and recalled a similar issue in the installer code.

We quote the program name in the installer shims.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356541157

From ihse at openjdk.org  Wed Sep 17 19:34:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 19:34:44 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v9]
In-Reply-To: <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <ShHsknSfV1QMrcKOi18kiHOt-j_TXnt1zI8GxXZQlJQ=.3ffb6eac-c6f1-4e88-8a9c-9ebb8a981d8a@github.com>
 <T-6mNw5dQ3ekKMr45zWK8IgrdOuqWkj_ytuH82q6Iug=.bc0c25ab-40ec-4df6-af08-2946a639b7e7@github.com>
 <QDE8bb7DkTIo9ZlOeMETrZfywVsPDYW-IpkyXUCAC7U=.cdf3c2de-5ae0-4f85-880c-c029c87986a6@github.com>
 <CG1WmHtAaz2_X7JcBhP6jWYy3hkJi-p3sB5NDL1r8nc=.65bc7235-3055-4a3c-8c30-2ca19d3aad8e@github.com>
 <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com>
 <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com>
Message-ID: <k_0E3GG-rJGHVgi3Nx3LT4rOM_4FWOKqJr2gUP41UcQ=.c45157ab-d79b-4070-b7e3-19a152d07e43@github.com>

On Wed, 17 Sep 2025 19:27:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Yes, I've read that blog post, tried to implement it and credited in the source code. :-)
>> 
>> The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it.
>> 
>> But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way.
>
> Oh, my bad :) I didn't dive into the source code. I came across this discussion and recalled a similar issue in the installer code.
> 
> We quote the program name in the installer shims.

No worries, that blog post is essential reading for anyone working with command line args on Windows, and it is a good thing that you try to spread knowledge about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356550461

From erikj at openjdk.org  Wed Sep 17 19:42:35 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 19:42:35 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
Message-ID: <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>

On Wed, 17 Sep 2025 15:16:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If the command line changes, it is reason to re-run the command.

make/common/Execute.gmk line 153:

> 151:   $1_VARDEPS := $$($1_COMMAND) $$($1_PRE_COMMAND) $$($1_POST_COMMAND)
> 152:   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS)
> 153:   $1_DEPS += $$($1_VARDEPS_FILE)

`$1_DEPS` is an input parameter. Should we really be appending to it inside the macro body?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27348#discussion_r2356576561

From bpb at openjdk.org  Wed Sep 17 21:01:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Sep 2025 21:01:15 GMT
Subject: RFR: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <xAoag4ATH0zmnClgZ9hKu4t3D1JgXNpXjTIrOAEp-T0=.be18279a-dfe2-4a16-8ea4-1605aa9ed16e@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
 <b44igbeyKvVtWIRL13bqAcHjImCXp4yREWa0-X4Ohis=.0315a222-4f4b-4258-80f4-87ce9301f9a6@github.com>
 <xAoag4ATH0zmnClgZ9hKu4t3D1JgXNpXjTIrOAEp-T0=.be18279a-dfe2-4a16-8ea4-1605aa9ed16e@github.com>
Message-ID: <t3CPDMq_YB8FsCJJqcepCkLR5hzzbY1bUEVnz9OchYA=.2011c642-16b2-45d5-bcb5-6c49bcccef5d@github.com>

On Wed, 17 Sep 2025 16:02:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this?
> 
> I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository.

I concur. Given that the only change since JDK 8 is this

59c59
<  * <tt>put</tt> or <tt>compact</tt> is invoked upon a read-only buffer." \
---
>  * <code>put</code> or <code>compact</code> is invoked upon a read-only buffer." \

these are pretty stable.

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

PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304544038

From david.holmes at oracle.com  Thu Sep 18 01:57:21 2025
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Sep 2025 11:57:21 +1000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>

Hi Matthias,

On 17/09/2025 11:41 pm, Baesken, Matthias wrote:
> Hi , when building Debian packages for 25 ,???? a couple of messages  
> complaining about ??useless?? dependencies ?show up .
> 
> One is about?? libjvm.so depending on?? librt.so.1 ????:
> 
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> 
> /usr/lib/jvm/jdk-25/lib/server/libjvm.so
> 
> were not linked against librt.so.1 (they use none of the library's symbols)
> 
> Looks like in old days, on old distros, this dependency was (maybe?) 
> still useful?? :
> 
> See? make/autoconf/libraries.m4? :
> 
> 139?? # librt for legacy clock_gettime
> 140?? if test "x$OPENJDK_TARGET_OS" = xlinux; then
> 141???? # Hotspot needs to link librt to get the clock_* functions.
> 142???? # But once our supported minimum build and runtime platform
> 143???? # has glibc 2.17, this can be removed as the functions are
> 144???? # in libc.
> 145???? BASIC_JVM_LIBS="$BASIC_JVM_LIBS -lrt"
> 146?? fi
> 
> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc 
> versions)
> 
> Could we clean this up?
> 
> Or is there still some need? to ?support this in jdk26? ?

I always find it very difficult to determine when checks like these 
become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux 
release we currently support.

Given I wrote the above in April 2021, I would hope we can now move on, 
but again I don't know how to readily determine that.

Cheers,
David

> Best regards, Matthias
> 


From dholmes at openjdk.org  Thu Sep 18 02:52:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Sep 2025 02:52:32 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <82IHZUHXIAjbljGxX27j7nsc8GUjTOCxNOXmYwiwlw8=.25ba5af1-4199-41cd-b75d-7758d7b51d34@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
 <82IHZUHXIAjbljGxX27j7nsc8GUjTOCxNOXmYwiwlw8=.25ba5af1-4199-41cd-b75d-7758d7b51d34@github.com>
Message-ID: <FCEJ7zj27UKLxIGVO1v4rBoDZ0SStyV2BvGOCm3Q1Ow=.5be779dc-e6a2-44bb-a1da-637273642ff7@github.com>

On Wed, 17 Sep 2025 10:02:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> How bad is the output with `-L`, really? I would have thought having more debugging info is better for post-mortem diagnostics -- especially if you cannot re-run the test -- even if it is more verbose.

As Jai states (though I filed the complaint :) ) the `-L` output actually obscures determining how many other processes are actually running. And while the number of threads in those other processes may be of some interest I can't see why we would need a breakdown at the thread-level for all those other processes.

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

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3305218975

From cstein at openjdk.org  Thu Sep 18 05:54:50 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 18 Sep 2025 05:54:50 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v6]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <U1kGdTKpm3CnGEY0GIfMbwDEyInJ6a6-Ox2jyxTR-Hw=.4f17c0b6-9aac-4b6f-be92-a664a1021c88@github.com>

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header
  
  [skip ci]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/7f2017b4..fd7bf6fd

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

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

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

From jpai at openjdk.org  Thu Sep 18 05:54:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Sep 2025 05:54:51 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v6]
In-Reply-To: <U1kGdTKpm3CnGEY0GIfMbwDEyInJ6a6-Ox2jyxTR-Hw=.4f17c0b6-9aac-4b6f-be92-a664a1021c88@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <U1kGdTKpm3CnGEY0GIfMbwDEyInJ6a6-Ox2jyxTR-Hw=.4f17c0b6-9aac-4b6f-be92-a664a1021c88@github.com>
Message-ID: <GTpujD4CS9YzEFwf9Ssvlc4OQ-RfQHNLFUr4jOONtEI=.7a5f7c26-586d-4435-9971-e3570ff3d9e2@github.com>

On Thu, 18 Sep 2025 05:52:07 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header
>   
>   [skip ci]

The latest changes in `fd7bf6f` look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3237379113

From matthias.baesken at sap.com  Thu Sep 18 07:15:31 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 18 Sep 2025 07:15:31 +0000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
Message-ID: <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>


>> 
>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc 
>> versions)
>> 
>> Could we clean this up?
>> 
>> Or is there still some need? to ?support this in jdk26? ?
>
>I always find it very difficult to determine when checks like these 
>become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux 
>release we currently support.
>
> Given I wrote the above in April 2021, I would hope we can now move on, 
> but again I don't know how to readily determine that.


I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?

Best regards, Matthias


From mbaesken at openjdk.org  Thu Sep 18 07:33:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Sep 2025 07:33:09 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
Message-ID: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>

A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

Commit messages:
 - JDK-8367913

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

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

From cstein at openjdk.org  Thu Sep 18 12:12:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 18 Sep 2025 12:12:31 GMT
Subject: Integrated: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <oSKqM5EPLZ7G-EOF3_AgGylPL-4cbjEHNYI2ccXIJ_w=.1cbb7d27-41a1-4d79-b80c-24faee973cfd@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request has now been integrated.

Changeset: 5db1dfe5
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5db1dfe5c8b5df40779bb450849e6433aa9825ab
Stats:     41 lines in 11 files changed: 9 ins; 19 del; 13 mod

8361950: Update to use jtreg 8

Reviewed-by: jpai, iris, joehw, erikj, ihse, liach, alanb

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

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

From clanger at openjdk.org  Thu Sep 18 12:55:14 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 18 Sep 2025 12:55:14 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <OB2a9gQR4TnW2g9jtSczijMfOY3qU6CTq6C5rpWMklI=.a71a921d-cd45-4f5a-bd72-ed38d01b064c@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Code changes look good but I guess somebody from Oracle has to verify this, whether it does not break unwanted things.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239492738

From mdoerr at openjdk.org  Thu Sep 18 13:03:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 18 Sep 2025 13:03:20 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <tvYCS02M14QNXmqLjLSB6bra7GT6BM4a7wNc9_HHWwI=.fa4022a3-4c51-4334-964d-74d174f34cf2@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

+1

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239571890

From erikj at openjdk.org  Thu Sep 18 13:15:40 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 13:15:40 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I have started a verification job with tier1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307387278

From erik.joelsson at oracle.com  Thu Sep 18 13:15:57 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 18 Sep 2025 06:15:57 -0700
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <f67444eb-248f-4e25-9cdc-3f773888cfcb@oracle.com>

The safe solution would be to check for a sample of the expected symbols 
in glibc in configure, but I'm not sure it's worth it. I doubt anyone 
builds with an older glibc than we do at Oracle, but you never know.

/Erik

On 9/18/25 00:15, Baesken, Matthias wrote:
>>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc
>>> versions)
>>>
>>> Could we clean this up?
>>>
>>> Or is there still some need? to ?support this in jdk26? ?
>> I always find it very difficult to determine when checks like these
>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
>> release we currently support.
>>
>> Given I wrote the above in April 2021, I would hope we can now move on,
>> but again I don't know how to readily determine that.
>
> I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?
>
> Best regards, Matthias
>

From matthias.baesken at sap.com  Thu Sep 18 13:40:01 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 18 Sep 2025 13:40:01 +0000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <f67444eb-248f-4e25-9cdc-3f773888cfcb@oracle.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <f67444eb-248f-4e25-9cdc-3f773888cfcb@oracle.com>
Message-ID: <DU2PR02MB1025819338EDE3D414B5F58539316A@DU2PR02MB10258.eurprd02.prod.outlook.com>

>The safe solution would be to check for a sample of the expected symbols 
>in glibc in configure, but I'm not sure it's worth it. I doubt anyone 
>builds with an older glibc than we do at Oracle, but you never know.


 I was considering this too, but on the other hand it adds complexity only to support some very old setups.
So I was unsure if it is worth it  .

Best regards, Matthias


From mbaesken at openjdk.org  Thu Sep 18 13:40:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Sep 2025 13:40:13 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
Message-ID: <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>

On Thu, 18 Sep 2025 13:13:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I have started a verification job with tier1-5.

Hi Erik, thanks for checking !

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307512079

From ihse at openjdk.org  Thu Sep 18 14:38:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 14:38:19 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

make/modules/java.base/Lib.gmk line 165:

> 163:     LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 164:     LDFLAGS_aix := -brtl -bexpfull, \
> 165:     LIBS_linux := $(LIBDL) $(LIBM), \

I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2359642913

From ihse at openjdk.org  Thu Sep 18 14:43:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 14:43:35 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
 <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>
Message-ID: <eC3Y1BwU_NyIKbYgKjB_GJbimq5sB51myttj0KaE7fQ=.158fcff9-fe50-4f82-941a-f6b79981623d@github.com>

On Wed, 17 Sep 2025 19:40:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> If the command line changes, it is reason to re-run the command.
>
> make/common/Execute.gmk line 153:
> 
>> 151:   $1_VARDEPS := $$($1_COMMAND) $$($1_PRE_COMMAND) $$($1_POST_COMMAND)
>> 152:   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS)
>> 153:   $1_DEPS += $$($1_VARDEPS_FILE)
> 
> `$1_DEPS` is an input parameter. Should we really be appending to it inside the macro body?

I think we usually do that? I mean, if I were programming in a proper language, I'd be horrified at the thought of changing a function argument. But with the limited expressiveness of make, I think this is okay.

What alternative would you prefer otherwise? That we create a new `$1_EXTRA_DEPS`, add the vardeps file to it, and insert `$$($1_EXTRA_DEPS)` wherever we have `$$($1_DEPS)`? Or explicitly adding the `$$($1_VARDEPS_FILE)` everywhere instead? I don't think any of these are necessarily better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27348#discussion_r2359665410

From ihse at openjdk.org  Thu Sep 18 14:50:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 14:50:18 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <MVyErx68K01TNoNDTJ3-UlvD-52jsHEZUzxQyw_sK4I=.63b6341d-78d0-40a9-80f4-eb589fd7726b@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Build changes look fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3240239228

From ihse at openjdk.org  Thu Sep 18 15:02:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 15:02:01 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
Message-ID: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>

An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

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

Commit messages:
 - Replace tab with spaces
 - 8367859: Remove nio exception gensrc

Changes: https://git.openjdk.org/jdk/pull/27352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367859
  Stats: 2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27352/head:pull/27352

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

From alanb at openjdk.org  Thu Sep 18 16:00:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Sep 2025 16:00:53 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
Message-ID: <jpx9mIMPDJco6G0qdOeOfkGAFsYsf6gMljGEf9Q7_Hk=.aae6b4fb-b56b-4412-b623-6f521fc5b62c@github.com>

On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2).

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

PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3308284366

From naoto at openjdk.org  Thu Sep 18 16:20:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Sep 2025 16:20:33 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
Message-ID: <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>

On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

charset package changes look good to me

src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30:

> 28: /**
> 29:  * Unchecked exception thrown when a string that is not a
> 30:  * <a href="Charset.html#names">legal charset name</a> is used as such.

Could utilize new construct as `{@linkplain Charset##names legal charset name}`

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240774915
PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360132337

From alanb at openjdk.org  Thu Sep 18 16:30:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Sep 2025 16:30:28 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
 <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>
Message-ID: <tDQlHbEZmTlSSVrZ4-0XNR0u9NRziO0c5HgrQ2BbOFg=.c3a659f1-ae88-40a8-89e4-9656fa8d9367@github.com>

On Thu, 18 Sep 2025 16:17:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.
>
> src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30:
> 
>> 28: /**
>> 29:  * Unchecked exception thrown when a string that is not a
>> 30:  * <a href="Charset.html#names">legal charset name</a> is used as such.
> 
> Could utilize new construct as `{@linkplain Charset##names legal charset name}`

I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360178485

From naoto at openjdk.org  Thu Sep 18 16:34:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Sep 2025 16:34:55 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <tDQlHbEZmTlSSVrZ4-0XNR0u9NRziO0c5HgrQ2BbOFg=.c3a659f1-ae88-40a8-89e4-9656fa8d9367@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
 <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>
 <tDQlHbEZmTlSSVrZ4-0XNR0u9NRziO0c5HgrQ2BbOFg=.c3a659f1-ae88-40a8-89e4-9656fa8d9367@github.com>
Message-ID: <jIhN3j-pzQr6E4POBol7dIvpd5fVtRrfyXp40yhxx_g=.df80915b-b6fc-43ac-ad3e-a141c8db430b@github.com>

On Thu, 18 Sep 2025 16:27:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30:
>> 
>>> 28: /**
>>> 29:  * Unchecked exception thrown when a string that is not a
>>> 30:  * <a href="Charset.html#names">legal charset name</a> is used as such.
>> 
>> Could utilize new construct as `{@linkplain Charset##names legal charset name}`
>
> I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize.

OK fair enough. I just noticed that the file was modified, ie.

// -- This file was mechanically generated: Do not edit! -- //

was removed, so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360197251

From erikj at openjdk.org  Thu Sep 18 16:45:21 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 16:45:21 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
Message-ID: <JYKztsTjnMwBHjE71F6abcXSros3mROO-Q5z8IT6wPs=.c74981f8-4e28-44b6-b672-e21886e35f39@github.com>

On Wed, 17 Sep 2025 15:16:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If the command line changes, it is reason to re-run the command.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27348#pullrequestreview-3240911888

From erikj at openjdk.org  Thu Sep 18 16:45:23 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 16:45:23 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <eC3Y1BwU_NyIKbYgKjB_GJbimq5sB51myttj0KaE7fQ=.158fcff9-fe50-4f82-941a-f6b79981623d@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
 <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>
 <eC3Y1BwU_NyIKbYgKjB_GJbimq5sB51myttj0KaE7fQ=.158fcff9-fe50-4f82-941a-f6b79981623d@github.com>
Message-ID: <A0PxvEjnB6WEHvtY4ZlmQn8b6PPzg7ZrzcoDrM3Pl3U=.2127259c-ffeb-4010-9c30-da28e4c02619@github.com>

On Thu, 18 Sep 2025 14:40:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/common/Execute.gmk line 153:
>> 
>>> 151:   $1_VARDEPS := $$($1_COMMAND) $$($1_PRE_COMMAND) $$($1_POST_COMMAND)
>>> 152:   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS)
>>> 153:   $1_DEPS += $$($1_VARDEPS_FILE)
>> 
>> `$1_DEPS` is an input parameter. Should we really be appending to it inside the macro body?
>
> I think we usually do that? I mean, if I were programming in a proper language, I'd be horrified at the thought of changing a function argument. But with the limited expressiveness of make, I think this is okay.
> 
> What alternative would you prefer otherwise? That we create a new `$1_EXTRA_DEPS`, add the vardeps file to it, and insert `$$($1_EXTRA_DEPS)` wherever we have `$$($1_DEPS)`? Or explicitly adding the `$$($1_VARDEPS_FILE)` everywhere instead? I don't think any of these are necessarily better.

I'm not going to fight for it, but I would most likely have gone with some variant of what you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27348#discussion_r2360244952

From erikj at openjdk.org  Thu Sep 18 16:47:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 16:47:16 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
Message-ID: <NU7I2DYkp18J7hvxKCAPLxnwG4OWU_USatLC2Rtz6tA=.d203b38d-3b2c-4ce1-ab82-97ea2368923f@github.com>

On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240922142

From jpai at openjdk.org  Thu Sep 18 16:49:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Sep 2025 16:49:10 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <AogKGywVWi7Z1vlOgcIKLd_DNl9gvK44vxlgaWY6Pr8=.ffcf06af-9cdf-468d-ae64-7ef8a75dc069@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Thank you David.

Aleksey, if it's OK with you, then I'll go ahead with the integration of this change tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3308513049

From alanb at openjdk.org  Thu Sep 18 16:54:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Sep 2025 16:54:07 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <jIhN3j-pzQr6E4POBol7dIvpd5fVtRrfyXp40yhxx_g=.df80915b-b6fc-43ac-ad3e-a141c8db430b@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
 <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>
 <tDQlHbEZmTlSSVrZ4-0XNR0u9NRziO0c5HgrQ2BbOFg=.c3a659f1-ae88-40a8-89e4-9656fa8d9367@github.com>
 <jIhN3j-pzQr6E4POBol7dIvpd5fVtRrfyXp40yhxx_g=.df80915b-b6fc-43ac-ad3e-a141c8db430b@github.com>
Message-ID: <Lg_OgYkGqLu92p8mx6U4iEe08aA-yvhUaGy2sGtPO1w=.66eec26e-583c-45c8-9ee2-671e7753fb6f@github.com>

On Thu, 18 Sep 2025 16:32:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize.
>
> OK fair enough. I just noticed that the file was modified, ie.
> 
> // -- This file was mechanically generated: Do not edit! -- //
> 
> was removed, so.

Yes, I think that has to be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360284037

From bpb at openjdk.org  Thu Sep 18 17:21:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Sep 2025 17:21:21 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
Message-ID: <8OZRZZyc6pyg8QAjOyt-3M_KJ3KF_YwZ-q9SaUmPvvw=.0cf09837-e46c-4da7-8293-a07a82a932f2@github.com>

On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3241093519

From shade at openjdk.org  Thu Sep 18 17:22:26 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Sep 2025 17:22:26 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <tTgChZRUqlOqOkTDbRDYQT3DyV0hi-dsYAvdG6M9ASM=.282fd6ef-2e8a-4009-bc7e-2e09d6ef4312@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Yeah, all right, I have no strong preference either way.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27328#pullrequestreview-3241098697

From ihse at openjdk.org  Thu Sep 18 17:28:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 17:28:26 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <Lg_OgYkGqLu92p8mx6U4iEe08aA-yvhUaGy2sGtPO1w=.66eec26e-583c-45c8-9ee2-671e7753fb6f@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
 <L5iamWehxkvvMQno4UgQdH1m3Y_mERBRXxqdyg-EbZw=.3eb824d3-33cd-4420-b369-545adcd2724f@github.com>
 <tDQlHbEZmTlSSVrZ4-0XNR0u9NRziO0c5HgrQ2BbOFg=.c3a659f1-ae88-40a8-89e4-9656fa8d9367@github.com>
 <jIhN3j-pzQr6E4POBol7dIvpd5fVtRrfyXp40yhxx_g=.df80915b-b6fc-43ac-ad3e-a141c8db430b@github.com>
 <Lg_OgYkGqLu92p8mx6U4iEe08aA-yvhUaGy2sGtPO1w=.66eec26e-583c-45c8-9ee2-671e7753fb6f@github.com>
Message-ID: <lYBIHUS3TYtgXbiGxrZ7lj5qERA2eYJg5FNfffJSHzA=.3091de81-38f4-46e8-a030-9c432bca34af@github.com>

On Thu, 18 Sep 2025 16:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> OK fair enough. I just noticed that the file was modified, ie.
>> 
>> // -- This file was mechanically generated: Do not edit! -- //
>> 
>> was removed, so.
>
> Yes, I think that has to be removed.

Alan is right, I just copied in the generated files. This is the files as generated by my previous PR. See this comment https://github.com/openjdk/jdk/pull/27338#issuecomment-3302348906 for details on how they differ. (Apart from a bug fix it is whitespace and comments only).

In addition to this, jcheck complained about the generated files containing tabs, so I also had to replace those with spaces. 

Please go ahead and modernize the code after this PR. :) (But how to do it "yesterday" eludes me ;-))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360419615

From ihse at openjdk.org  Thu Sep 18 17:33:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Sep 2025 17:33:22 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <A0PxvEjnB6WEHvtY4ZlmQn8b6PPzg7ZrzcoDrM3Pl3U=.2127259c-ffeb-4010-9c30-da28e4c02619@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
 <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>
 <eC3Y1BwU_NyIKbYgKjB_GJbimq5sB51myttj0KaE7fQ=.158fcff9-fe50-4f82-941a-f6b79981623d@github.com>
 <A0PxvEjnB6WEHvtY4ZlmQn8b6PPzg7ZrzcoDrM3Pl3U=.2127259c-ffeb-4010-9c30-da28e4c02619@github.com>
Message-ID: <zpviF-YdAW3K-IOfOrTjB4NVjk4GhRFeIKlNxlWXtf0=.23c1a412-8485-4267-ab27-6a68e9127099@github.com>

On Thu, 18 Sep 2025 16:42:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I think we usually do that? I mean, if I were programming in a proper language, I'd be horrified at the thought of changing a function argument. But with the limited expressiveness of make, I think this is okay.
>> 
>> What alternative would you prefer otherwise? That we create a new `$1_EXTRA_DEPS`, add the vardeps file to it, and insert `$$($1_EXTRA_DEPS)` wherever we have `$$($1_DEPS)`? Or explicitly adding the `$$($1_VARDEPS_FILE)` everywhere instead? I don't think any of these are necessarily better.
>
> I'm not going to fight for it, but I would most likely have gone with some variant of what you suggested.

I'm not going to fight for my solution either. :) Which would you prefer, explicitly adding vardeps, or creating a new general extra-deps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27348#discussion_r2360439782

From erikj at openjdk.org  Thu Sep 18 18:17:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 18:17:54 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
In-Reply-To: <zpviF-YdAW3K-IOfOrTjB4NVjk4GhRFeIKlNxlWXtf0=.23c1a412-8485-4267-ab27-6a68e9127099@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
 <3LW9ASRYs84gxdo9Y1gSd0i4It19KRH5q9qQfJ0irs4=.96e1c11f-c231-4e74-883d-c1806fb0cf21@github.com>
 <eC3Y1BwU_NyIKbYgKjB_GJbimq5sB51myttj0KaE7fQ=.158fcff9-fe50-4f82-941a-f6b79981623d@github.com>
 <A0PxvEjnB6WEHvtY4ZlmQn8b6PPzg7ZrzcoDrM3Pl3U=.2127259c-ffeb-4010-9c30-da28e4c02619@github.com>
 <zpviF-YdAW3K-IOfOrTjB4NVjk4GhRFeIKlNxlWXtf0=.23c1a412-8485-4267-ab27-6a68e9127099@github.com>
Message-ID: <18zPCVTRYnlFlhQVRbKAugG5sfEMmYZTaF502T5R8pU=.2929cbd8-a69b-440a-ae81-e0b3fc12a5d1@github.com>

On Thu, 18 Sep 2025 17:30:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I'm not going to fight for it, but I would most likely have gone with some variant of what you suggested.
>
> I'm not going to fight for my solution either. :) Which would you prefer, explicitly adding vardeps, or creating a new general extra-deps?

In this case I think I would have kept it simple and just added `$1_VARDEPS` on the prerequisite lines where needed, but again, I don't really mind either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27348#discussion_r2360604864

From jpai at openjdk.org  Fri Sep 19 01:39:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Sep 2025 01:39:41 GMT
Subject: RFR: 8367801: jtreg failure_handler - don't use the -L option for
 ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <X0cVnhQwg3kAT4WJKrqO4UZxMEj4Rz4Kl5fvoRKNBYk=.5959273e-fc22-41f0-a33f-c781f031f71b@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3310180359

From jpai at openjdk.org  Fri Sep 19 01:39:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Sep 2025 01:39:42 GMT
Subject: Integrated: 8367801: jtreg failure_handler - don't use the -L option
 for ps command
In-Reply-To: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
References: <t5puPyfx9G9hG-eR-Tk5uZ7ywY8UAD2xZuZBClC-Oxc=.872dc89c-d81d-4485-9514-3846ff481b1c@github.com>
Message-ID: <F_jZ94PHKqtvpHHkYjD999K_bGS_5InsX74QYmfqPXQ=.dae24a08-6597-4423-8db5-910a7bfc58bd@github.com>

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

This pull request has now been integrated.

Changeset: 7ec3fa5f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ec3fa5f0a7408bf70e6226814d80dabd8a1a93c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8367801: jtreg failure_handler - don't use the -L option for ps command

Reviewed-by: ayang, shade

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

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

From david.holmes at oracle.com  Fri Sep 19 04:28:14 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Sep 2025 14:28:14 +1000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>

On 18/09/2025 5:15 pm, Baesken, Matthias wrote:
> 
>>>
>>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc
>>> versions)
>>>
>>> Could we clean this up?
>>>
>>> Or is there still some need? to ?support this in jdk26? ?
>>
>> I always find it very difficult to determine when checks like these
>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
>> release we currently support.
>>
>> Given I wrote the above in April 2021, I would hope we can now move on,
>> but again I don't know how to readily determine that.
> 
> 
> I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?

I don't have access to such systems for testing.

David

> Best regards, Matthias
> 


From prr at openjdk.org  Fri Sep 19 07:24:51 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Sep 2025 07:24:51 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
Message-ID: <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>

On Thu, 18 Sep 2025 13:37:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I have started a verification job with tier1-5.

If that passes, then it is very likely OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310536470

From mbaesken at openjdk.org  Fri Sep 19 07:24:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 07:24:53 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <gd_5h2ho7Pr5DuHfHkY05xyYpu2cXSi149sZOitcJGc=.79e7a719-75a6-4c41-9182-c6d1e5a560d7@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I can bring back  the LIBDL  dependency  of   BUILD_LIBSYSLOOKUP if we are unsure about this single removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310964805

From mbaesken at openjdk.org  Fri Sep 19 07:24:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 07:24:55 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
Message-ID: <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>

On Thu, 18 Sep 2025 14:36:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.


Is there some test for this special functionality?

The comments in the C sources
https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c

do not really help me to understand what functions from libdl we want to bring in this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362019646

From matthias.baesken at sap.com  Fri Sep 19 07:42:19 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 19 Sep 2025 07:42:19 +0000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>
Message-ID: <DU2PR02MB10258D7330604707C2DADDFB39311A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi David, I found a RHEL  7.9   machine with an old glibc  :

ldd --version
ldd (GNU libc) 2.17

But the gcc on this machine  is 4.8.5  , probably too  old   to build OpenJDK there to see  if this change breaks something .

Any idea what I should test  on this old machine  regarding librt.so.1   ? 


Best regards, Matthias



>>>>
>>>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc
>>>> versions)
>>>>
>>>> Could we clean this up?
>>>>
>>>> Or is there still some need? to ?support this in jdk26? ?
>>>
>>> I always find it very difficult to determine when checks like these
>>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
>>> release we currently support.
>>>
>>> Given I wrote the above in April 2021, I would hope we can now move on,
>>> but again I don't know how to readily determine that.
>> 
>> 
>> I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?
>
>I don't have access to such systems for testing.
>
>David



From ihse at openjdk.org  Fri Sep 19 09:11:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 09:11:25 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

I've pinged Maurizio about libsyslookup; let's hear what he says first.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3311373364

From ihse at openjdk.org  Fri Sep 19 09:11:28 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 09:11:28 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
Message-ID: <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>

On Fri, 19 Sep 2025 07:20:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 165:
>> 
>>> 163:     LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
>>> 164:     LDFLAGS_aix := -brtl -bexpfull, \
>>> 165:     LIBS_linux := $(LIBDL) $(LIBM), \
>> 
>> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.
>
>> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used.
> 
> 
> Is there some test for this special functionality?
> 
> The comments in the C sources
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c
> 
> do not really help me to understand what functions from libdl we want to bring in this way.

@mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362260334

From ihse at openjdk.org  Fri Sep 19 09:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 09:21:00 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
 [v2]
In-Reply-To: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
Message-ID: <Najx5qWFNo5aMV52lBUx3vF07wfPhifUO8SN5OGkb0U=.9aa47f36-c5e4-4394-8dfb-e8d9ef92a628@github.com>

> If the command line changes, it is reason to re-run the command.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update per review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27348/files
  - new: https://git.openjdk.org/jdk/pull/27348/files/c1d25650..e914d4cd

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

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

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

From ihse at openjdk.org  Fri Sep 19 10:05:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 10:05:20 GMT
Subject: RFR: 8367859: Remove nio exception gensrc
In-Reply-To: <jpx9mIMPDJco6G0qdOeOfkGAFsYsf6gMljGEf9Q7_Hk=.aae6b4fb-b56b-4412-b623-6f521fc5b62c@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
 <jpx9mIMPDJco6G0qdOeOfkGAFsYsf6gMljGEf9Q7_Hk=.aae6b4fb-b56b-4412-b623-6f521fc5b62c@github.com>
Message-ID: <9Ct4IC_vPNBSZ3ynx8D30co9slKicJkZmoSZGel9WC4=.c965130b-6787-4cd7-94c3-1cb2686e6999@github.com>

On Thu, 18 Sep 2025 15:58:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2).

Yes, they pass with flying colors.

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

PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3311543989

From ihse at openjdk.org  Fri Sep 19 10:08:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 10:08:18 GMT
Subject: Withdrawn: 8367859: Remove shell script from nio exception gensrc
In-Reply-To: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
References: <TPmhWiU5WQoCMnhhHCqOikbC7d9_DrT-0LZ4bQ8AoeA=.62d3d717-9d0b-4cdf-9b7d-1a52b65b910d@github.com>
Message-ID: <v_ksiQLzki512i8Q5NsSdkWBii3KYEC_m6NH4ezK1eA=.9d4dfff3-9be8-463c-a1f1-ff649e5bd1f3@github.com>

On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls).

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Fri Sep 19 10:09:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 10:09:39 GMT
Subject: Integrated: 8367859: Remove nio exception gensrc
In-Reply-To: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
References: <vAMVZoUSWKB3tjkdved-U84ubA-4b0fTBGML2iSupAY=.c8953896-39e5-4692-a3c6-e604fcc4b841@github.com>
Message-ID: <i9sP93ck8sQtMdd9hd3FhxkVtcC63n4-4VYv5YSilT8=.8da4fbc9-a44e-4fca-aee8-448379a23c70@github.com>

On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files.

This pull request has now been integrated.

Changeset: 65aea485
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65aea485884134743fbd3da355bd1f861b410704
Stats:     2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod

8367859: Remove nio exception gensrc

Reviewed-by: naoto, erikj, bpb

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

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

From matthias.baesken at sap.com  Fri Sep 19 12:21:27 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 19 Sep 2025 12:21:27 +0000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <DU2PR02MB10258D7330604707C2DADDFB39311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>
 <DU2PR02MB10258D7330604707C2DADDFB39311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <DU2PR02MB10258BE7BCD5BF2B571F4D8F69311A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi David,  even  on RHEL   7.9   it works without  adding  -lrt to  linking , see the example   :


gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc clock_gettime.c -o clock_gettime
./clock_gettime
Elapsed time: 2.008803 seconds

more ./clock_gettime.c
#include <stdio.h>
#include <time.h>
#include <unistd.h>

int main() {
    struct timespec start, end;
    double elapsed;

    // Get start time
    clock_gettime(CLOCK_MONOTONIC, &start);

    // Simulate some work (sleep for 2 seconds)
    sleep(2);

    // Get end time
    clock_gettime(CLOCK_MONOTONIC, &end);

    // Calculate elapsed time in seconds (as a double)
    elapsed = (end.tv_sec - start.tv_sec);
    elapsed += (end.tv_nsec - start.tv_nsec) / 1e9;

    printf("Elapsed time: %.6f seconds\n", elapsed);

    return 0;
}


ldd --version
ldd (GNU libc) 2.17



But  on ancient   SLES 11  (SUSE Linux 11)  with
ldd --version
ldd (GNU libc) 2.11.3


I see the issue  ,  there I have to add   -lrt  :

gcc  clock_gettime.c  -o   clock_gettime
/tmp/ccU07fSz.o: In function `main':
clock_gettime.c:(.text+0x20): undefined reference to `clock_gettime'
clock_gettime.c:(.text+0x40): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status


gcc  clock_gettime.c  -o   clock_gettime -lrt
./clock_gettime
Elapsed time: 2.000108 seconds


So it seems we have to go back to SLES11   and RHEL 6  (!)   for this strange  librt  issue .

Best regards, Matthias



-----Original Message-----
From: Baesken, Matthias 
Sent: Friday, 19 September 2025 09:42
To: 'David Holmes' <david.holmes at oracle.com>; build-dev at openjdk.org; hotspot-dev <hotspot-dev-retn at openjdk.org>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: "useless" librt.so.1 dependency on Linux reported by dpkg-shlibdeps

Hi David, I found a RHEL  7.9   machine with an old glibc  :

ldd --version
ldd (GNU libc) 2.17

But the gcc on this machine  is 4.8.5  , probably too  old   to build OpenJDK there to see  if this change breaks something .

Any idea what I should test  on this old machine  regarding librt.so.1   ? 


Best regards, Matthias



>>>>
>>>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc
>>>> versions)
>>>>
>>>> Could we clean this up?
>>>>
>>>> Or is there still some need? to ?support this in jdk26? ?
>>>
>>> I always find it very difficult to determine when checks like these
>>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
>>> release we currently support.
>>>
>>> Given I wrote the above in April 2021, I would hope we can now move on,
>>> but again I don't know how to readily determine that.
>> 
>> 
>> I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?
>
>I don't have access to such systems for testing.
>
>David



From david.holmes at oracle.com  Fri Sep 19 12:39:28 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Sep 2025 22:39:28 +1000
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <DU2PR02MB10258BE7BCD5BF2B571F4D8F69311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>
 <DU2PR02MB10258D7330604707C2DADDFB39311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <DU2PR02MB10258BE7BCD5BF2B571F4D8F69311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <d11738c2-a516-4d75-bad6-f3ab8cf64cf3@oracle.com>

On 19/09/2025 10:21 pm, Baesken, Matthias wrote:
> Hi David,  even  on RHEL   7.9   it works without  adding  -lrt to  linking , see the example   :

It is only pre glibc 2.17 that we need librt.so for.

David

> 
> gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> gcc clock_gettime.c -o clock_gettime
> ./clock_gettime
> Elapsed time: 2.008803 seconds
> 
> more ./clock_gettime.c
> #include <stdio.h>
> #include <time.h>
> #include <unistd.h>
> 
> int main() {
>      struct timespec start, end;
>      double elapsed;
> 
>      // Get start time
>      clock_gettime(CLOCK_MONOTONIC, &start);
> 
>      // Simulate some work (sleep for 2 seconds)
>      sleep(2);
> 
>      // Get end time
>      clock_gettime(CLOCK_MONOTONIC, &end);
> 
>      // Calculate elapsed time in seconds (as a double)
>      elapsed = (end.tv_sec - start.tv_sec);
>      elapsed += (end.tv_nsec - start.tv_nsec) / 1e9;
> 
>      printf("Elapsed time: %.6f seconds\n", elapsed);
> 
>      return 0;
> }
> 
> 
> ldd --version
> ldd (GNU libc) 2.17
> 
> 
> 
> But  on ancient   SLES 11  (SUSE Linux 11)  with
> ldd --version
> ldd (GNU libc) 2.11.3
> 
> 
> I see the issue  ,  there I have to add   -lrt  :
> 
> gcc  clock_gettime.c  -o   clock_gettime
> /tmp/ccU07fSz.o: In function `main':
> clock_gettime.c:(.text+0x20): undefined reference to `clock_gettime'
> clock_gettime.c:(.text+0x40): undefined reference to `clock_gettime'
> collect2: ld returned 1 exit status
> 
> 
> gcc  clock_gettime.c  -o   clock_gettime -lrt
> ./clock_gettime
> Elapsed time: 2.000108 seconds
> 
> 
> So it seems we have to go back to SLES11   and RHEL 6  (!)   for this strange  librt  issue .
> 
> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Friday, 19 September 2025 09:42
> To: 'David Holmes' <david.holmes at oracle.com>; build-dev at openjdk.org; hotspot-dev <hotspot-dev-retn at openjdk.org>
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: RE: "useless" librt.so.1 dependency on Linux reported by dpkg-shlibdeps
> 
> Hi David, I found a RHEL  7.9   machine with an old glibc  :
> 
> ldd --version
> ldd (GNU libc) 2.17
> 
> But the gcc on this machine  is 4.8.5  , probably too  old   to build OpenJDK there to see  if this change breaks something .
> 
> Any idea what I should test  on this old machine  regarding librt.so.1   ?
> 
> 
> Best regards, Matthias
> 
> 
> 
>>>>>
>>>>> ( seems some versions of? RHEL 7? / SLES 12? still had those old glibc
>>>>> versions)
>>>>>
>>>>> Could we clean this up?
>>>>>
>>>>> Or is there still some need? to ?support this in jdk26? ?
>>>>
>>>> I always find it very difficult to determine when checks like these
>>>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
>>>> release we currently support.
>>>>
>>>> Given I wrote the above in April 2021, I would hope we can now move on,
>>>> but again I don't know how to readily determine that.
>>>
>>>
>>> I could create a removal PR and maybe you can test on the oldest platforms you want to support in release 26 ?
>>
>> I don't have access to such systems for testing.
>>
>> David
> 
> 


From erikj at openjdk.org  Fri Sep 19 12:45:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 Sep 2025 12:45:17 GMT
Subject: RFR: 8366899: SetupExecute should add the command line to vardeps
 [v2]
In-Reply-To: <Najx5qWFNo5aMV52lBUx3vF07wfPhifUO8SN5OGkb0U=.9aa47f36-c5e4-4394-8dfb-e8d9ef92a628@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
 <Najx5qWFNo5aMV52lBUx3vF07wfPhifUO8SN5OGkb0U=.9aa47f36-c5e4-4394-8dfb-e8d9ef92a628@github.com>
Message-ID: <JI7hJ5uZ0bdIZ60NLhDtwqirXugK_9go7FCyYdfkWB8=.62cefb76-699d-434f-aa6a-b400a5f6f6ff@github.com>

On Fri, 19 Sep 2025 09:21:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> If the command line changes, it is reason to re-run the command.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update per review comment

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27348#pullrequestreview-3244691273

From erikj at openjdk.org  Fri Sep 19 12:52:38 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 Sep 2025 12:52:38 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
 <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
Message-ID: <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>

On Fri, 19 Sep 2025 04:43:29 GMT, Phil Race <prr at openjdk.org> wrote:

> I have started a verification job with tier1-5.

Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312072392

From mbaesken at openjdk.org  Fri Sep 19 12:52:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Sep 2025 12:52:39 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com>
 <bXYLnG41HKGS0tiUwjWLz-0aq9PKsGUaNA8b29brR9E=.252c5ca1-13c7-435b-a734-fceeb4178c5d@github.com>
 <NL0v01IMgDJJju_MFEPumkhfuFnX3ilRWbDzKOkWVlA=.97429c51-f72c-4218-a382-b720831a81b1@github.com>
 <k-ErB2Uzn7cQcQ1lmFQGCVGxuZFGeRhzsjT-g_t_QVA=.05600278-1b61-464d-9f2c-645767a05d62@github.com>
Message-ID: <bkYc0lk7sATs4w1qSEdV16QC4sXMMlp6Y6zi1ag4WSc=.813768a2-e48a-437e-818c-35c7c30cd2f5@github.com>

On Fri, 19 Sep 2025 12:48:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I have started a verification job with tier1-5.
> 
> Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed.


Thanks for the testing !  So let's wait for some feedback on  libsyslookup  .

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312079386

From thomas.stuefe at gmail.com  Fri Sep 19 13:03:06 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 19 Sep 2025 15:03:06 +0200
Subject: "useless" librt.so.1 dependency on Linux reported by
 dpkg-shlibdeps
In-Reply-To: <d11738c2-a516-4d75-bad6-f3ab8cf64cf3@oracle.com>
References: <DU2PR02MB1025848DD65FD0E12A3EBD6B39317A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <6e4f59b2-86a6-43df-b98e-8f360b1a2734@oracle.com>
 <DU2PR02MB1025809752236A32DB6C4B5009316A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <45430060-6d4f-4ab3-94ca-52997467b5a8@oracle.com>
 <DU2PR02MB10258D7330604707C2DADDFB39311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <DU2PR02MB10258BE7BCD5BF2B571F4D8F69311A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <d11738c2-a516-4d75-bad6-f3ab8cf64cf3@oracle.com>
Message-ID: <CAA-vtUws68Od2yiH7WS8j5Vvq79PVf+8vDt4qSeyu1vw-R85tw@mail.gmail.com>

Hi,

AFAICS glibc 2.17 (or later) are supported in:

- RHEL 7.9 and later
- Oracle 7.9 and later (direct RHEL spinoff, same versioning)
- SLES 12 SP5 and later
- Debian: Jessie (Debian 8) and anything later. Jessie not supported
anymore. Current oldoldstable is Bullseye (Debian 11).
- Raspbian: any version after 2017, basically.
- Ubuntu: 14.04 and anything later. 14.04 is the last version Canonical
still sells support for, AFAIK.

Noteworthy still supported commercial Linuxes with older glibcs: AFAICS
only RHEL 6.9. We (IBM, Redhat) don't care about JDK 26 on these old
systems.

Cheers, Thomas



On Fri, Sep 19, 2025 at 2:39?PM David Holmes <david.holmes at oracle.com>
wrote:

> On 19/09/2025 10:21 pm, Baesken, Matthias wrote:
> > Hi David,  even  on RHEL   7.9   it works without  adding  -lrt to
> linking , see the example   :
>
> It is only pre glibc 2.17 that we need librt.so for.
>
> David
>
> >
> > gcc --version
> > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> >
> > gcc clock_gettime.c -o clock_gettime
> > ./clock_gettime
> > Elapsed time: 2.008803 seconds
> >
> > more ./clock_gettime.c
> > #include <stdio.h>
> > #include <time.h>
> > #include <unistd.h>
> >
> > int main() {
> >      struct timespec start, end;
> >      double elapsed;
> >
> >      // Get start time
> >      clock_gettime(CLOCK_MONOTONIC, &start);
> >
> >      // Simulate some work (sleep for 2 seconds)
> >      sleep(2);
> >
> >      // Get end time
> >      clock_gettime(CLOCK_MONOTONIC, &end);
> >
> >      // Calculate elapsed time in seconds (as a double)
> >      elapsed = (end.tv_sec - start.tv_sec);
> >      elapsed += (end.tv_nsec - start.tv_nsec) / 1e9;
> >
> >      printf("Elapsed time: %.6f seconds\n", elapsed);
> >
> >      return 0;
> > }
> >
> >
> > ldd --version
> > ldd (GNU libc) 2.17
> >
> >
> >
> > But  on ancient   SLES 11  (SUSE Linux 11)  with
> > ldd --version
> > ldd (GNU libc) 2.11.3
> >
> >
> > I see the issue  ,  there I have to add   -lrt  :
> >
> > gcc  clock_gettime.c  -o   clock_gettime
> > /tmp/ccU07fSz.o: In function `main':
> > clock_gettime.c:(.text+0x20): undefined reference to `clock_gettime'
> > clock_gettime.c:(.text+0x40): undefined reference to `clock_gettime'
> > collect2: ld returned 1 exit status
> >
> >
> > gcc  clock_gettime.c  -o   clock_gettime -lrt
> > ./clock_gettime
> > Elapsed time: 2.000108 seconds
> >
> >
> > So it seems we have to go back to SLES11   and RHEL 6  (!)   for this
> strange  librt  issue .
> >
> > Best regards, Matthias
> >
> >
> >
> > -----Original Message-----
> > From: Baesken, Matthias
> > Sent: Friday, 19 September 2025 09:42
> > To: 'David Holmes' <david.holmes at oracle.com>; build-dev at openjdk.org;
> hotspot-dev <hotspot-dev-retn at openjdk.org>
> > Cc: Langer, Christoph <christoph.langer at sap.com>
> > Subject: RE: "useless" librt.so.1 dependency on Linux reported by
> dpkg-shlibdeps
> >
> > Hi David, I found a RHEL  7.9   machine with an old glibc  :
> >
> > ldd --version
> > ldd (GNU libc) 2.17
> >
> > But the gcc on this machine  is 4.8.5  , probably too  old   to build
> OpenJDK there to see  if this change breaks something .
> >
> > Any idea what I should test  on this old machine  regarding librt.so.1
>  ?
> >
> >
> > Best regards, Matthias
> >
> >
> >
> >>>>>
> >>>>> ( seems some versions of  RHEL 7  / SLES 12  still had those old
> glibc
> >>>>> versions)
> >>>>>
> >>>>> Could we clean this up?
> >>>>>
> >>>>> Or is there still some need  to  support this in jdk26  ?
> >>>>
> >>>> I always find it very difficult to determine when checks like these
> >>>> become unnecessary. I think RHEL 7 with glibc 2.17 is the oldest Linux
> >>>> release we currently support.
> >>>>
> >>>> Given I wrote the above in April 2021, I would hope we can now move
> on,
> >>>> but again I don't know how to readily determine that.
> >>>
> >>>
> >>> I could create a removal PR and maybe you can test on the oldest
> platforms you want to support in release 26 ?
> >>
> >> I don't have access to such systems for testing.
> >>
> >> David
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250919/9cebd0ec/attachment.htm>

From ihse at openjdk.org  Fri Sep 19 13:07:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 13:07:01 GMT
Subject: Integrated: 8366899: SetupExecute should add the command line to
 vardeps
In-Reply-To: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
References: <Xx1MFylbYjQY0dYJbTi1DKuhMCSLmzERRvtSS9MWv_k=.657a58d3-c211-4639-9764-e75e4b1bbbcf@github.com>
Message-ID: <tpfQi_JYb-N-H4PlGtxeSXNZRh31KTFKUXpUuZ_gxUE=.e9f1250d-af16-40f5-a1e1-db58a896462f@github.com>

On Wed, 17 Sep 2025 15:16:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If the command line changes, it is reason to re-run the command.

This pull request has now been integrated.

Changeset: 2b7eee4a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b7eee4a4c1e8b9421c5db601da83000c344b78e
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8366899: SetupExecute should add the command line to vardeps

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Fri Sep 19 17:12:34 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 17:12:34 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk
Message-ID: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>

We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.

We should move them to normal .gmk code, and rename them.

The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

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

Commit messages:
 - 8368102: Don't store macros in spec.gmk

Changes: https://git.openjdk.org/jdk/pull/27394/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368102
  Stats: 109 lines in 8 files changed: 61 ins; 40 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27394/head:pull/27394

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

From ihse at openjdk.org  Fri Sep 19 17:12:34 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 17:12:34 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <7QPQFICs9Rv51qIrGf_gD6QfIdHYz1Rh7pyOGt2AzO8=.ccc4f133-7775-42ea-90c6-b4283e33fdc2@github.com>

On Fri, 19 Sep 2025 16:43:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

It is clear that this refactoring lends itself towards even more cleanups, but I'll save that for another day.

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

PR Comment: https://git.openjdk.org/jdk/pull/27394#issuecomment-3312917661

From aivanov at openjdk.org  Fri Sep 19 18:47:38 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Sep 2025 18:47:38 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <UXOkGVZd9q2spYKsQtxziAqvkaa8akLvLSYZ-SdbbPQ=.708f7081-b007-4c31-a016-86c07c225825@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3246478887

From ihse at openjdk.org  Fri Sep 19 19:21:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 19 Sep 2025 19:21:11 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <yOexna08uWR63Ea39bRVH9Drg53-22IHcRvPBXpbKMk=.29c80847-291e-40a3-a754-563c6c2e0f3a@github.com>

On Fri, 19 Sep 2025 16:43:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

Testing "builds" tier 1-5 in Oracle internal CI + COMPARE_BUILD with no differences.

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

PR Comment: https://git.openjdk.org/jdk/pull/27394#issuecomment-3313512266

From stuefe at openjdk.org  Sat Sep 20 07:47:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 20 Sep 2025 07:47:51 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
Message-ID: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>

ASAN, when catching an error, will abort the process.

Two things control this:
1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.

We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.

I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.

What would that give us?

By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.

And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.

And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

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

Commit messages:
 - JDK-8368176-ASAN-should-not-inhibit-hs-err-file-generation

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

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

From syan at openjdk.org  Sat Sep 20 14:25:13 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Sep 2025 14:25:13 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <y70MDA1wjQrThJ-g8y4jWXX-veMEfwS62e8ow-uIAr8=.48599c44-6c0f-4180-a29a-97bc1d12bdb7@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

make/autoconf/jdk-options.m4 line 464:

> 462:         elif test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
> 463:           # -Oy- is equivalent to -fno-omit-frame-pointer in GCC/Clang.
> 464:           ASAN_CFLAGS="-fsanitize=address -Oy- -DADDRESS_SANITIZER"

Does the `-fsanitize-recover=address` compiler options supported when TOOLCHAIN_TYPE == microsoft

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27404#discussion_r2365646161

From syan at openjdk.org  Sat Sep 20 14:30:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 20 Sep 2025 14:30:19 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <c275OWHpSAwbt8Y0Ls-LndHh9LaU-j3PhrUgABIV_gk=.9bfb6eb1-df52-4711-adb7-bc03ac337089@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

Hi, jdk support address sanitizer and leak sanitizer for now. It seems that this PR only concern address sanitizer, does the leak sanitizer also need this enhancement

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3315002815

From jwaters at openjdk.org  Sat Sep 20 16:28:17 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 20 Sep 2025 16:28:17 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <-TQ8gJfoLtBxR5Xwb2cxl0Eg46xdkE1O_MzwSBlIWHU=.447120d3-b162-46f0-8679-65c9bc959032@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters 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 branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/668267cb...9d05cb8e

Please give me more time, the flatten issue on my end is still causing problems

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3315086813

From wenanjian at openjdk.org  Sun Sep 21 00:50:18 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Sun, 21 Sep 2025 00:50:18 GMT
Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v7]
In-Reply-To: <NNd3kziE2dM8snLmu-n1vebuYQ-rXlr7u_CiEE4ETnc=.b63e1623-a720-47d4-b5d3-c17c12ea689b@github.com>
References: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
 <CK9saRbHrBxaXya098IIqpafnO3lI90UJ1ryPwuXP14=.0ed5e960-675a-4808-a96a-eae2c4f09e07@github.com>
 <NNd3kziE2dM8snLmu-n1vebuYQ-rXlr7u_CiEE4ETnc=.b63e1623-a720-47d4-b5d3-c17c12ea689b@github.com>
Message-ID: <6-c0fA19VDBsLUwN2ewcYQ_bPSD7Zt6h5lsIOhTMGpk=.80f0aca5-601b-48dd-9c0e-c79612976da9@github.com>

On Fri, 19 Sep 2025 07:09:27 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Anjian Wen 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into aes_ctr
>>  - fix the counter increase at limit and add test
>>  - change format
>>  - update reg use and instruction
>>  - change some name and format
>>  - delete useless Label, change L_judge_used to L_slow_loop
>>  - add Flags and fix the stubid name
>>  - RISC-V: implement AES-CTR mode intrinsics
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2667:
> 
>> 2665:     __ addi(t0, counter, 8);
>> 2666:     __ ld(tmp, Address(t0));
>> 2667:     __ rev8(tmp, tmp);
> 
> Note that `rev8` is only available under `UseZbb`. Maybe you should use `revb/revbw` instead which considers that the availability of Zbb extension.

I used the zbb and zvbb instructions in my patch?which seem not easy to replace in vector operations, and there are some optimizations when using them, so I think we may add a extension check in vm_version_riscv.cpp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2365883933

From wenanjian at openjdk.org  Sun Sep 21 00:57:40 2025
From: wenanjian at openjdk.org (Anjian Wen)
Date: Sun, 21 Sep 2025 00:57:40 GMT
Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v9]
In-Reply-To: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
References: <mMLCDK4Ls37Ebs_3LEM4dktuylNraobBebijN1BxZwM=.30730d56-b8ca-46c9-9dc2-1ca215e66ba4@github.com>
Message-ID: <cDlhsc0IV-1JuE3jtTj3GNKN4dvjMDYHCRU_lgdS0C4=.1e573495-5c40-4a27-8137-d1149d643ef3@github.com>

> Hi everyone, please help review this patch which Implement the _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled, the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed.

Anjian Wen has updated the pull request incrementally with one additional commit since the last revision:

  add zbb and zvbb check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25281/files
  - new: https://git.openjdk.org/jdk/pull/25281/files/35f82e0a..529f7cf8

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

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

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

From kbarrett at openjdk.org  Sun Sep 21 06:01:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 21 Sep 2025 06:01:14 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
In-Reply-To: <y70MDA1wjQrThJ-g8y4jWXX-veMEfwS62e8ow-uIAr8=.48599c44-6c0f-4180-a29a-97bc1d12bdb7@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
 <y70MDA1wjQrThJ-g8y4jWXX-veMEfwS62e8ow-uIAr8=.48599c44-6c0f-4180-a29a-97bc1d12bdb7@github.com>
Message-ID: <M19KIXLuJ0PDSOfOK2ou8NHSlaMlaMzPsX1wr6OmYv0=.ebbb42a9-d142-49d2-8208-7fd93b358fed@github.com>

On Sat, 20 Sep 2025 14:22:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> ASAN, when catching an error, will abort the process.
>> 
>> Two things control this:
>> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
>> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
>> 
>> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
>> 
>> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
>> 
>> What would that give us?
>> 
>> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
>> 
>> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
>> 
>> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.
>
> make/autoconf/jdk-options.m4 line 464:
> 
>> 462:         elif test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
>> 463:           # -Oy- is equivalent to -fno-omit-frame-pointer in GCC/Clang.
>> 464:           ASAN_CFLAGS="-fsanitize=address -Oy- -DADDRESS_SANITIZER"
> 
> Does the `-fsanitize-recover=address` compiler options supported when TOOLCHAIN_TYPE == microsoft

Looking at Visual Studio documentation and such, it looks like `-fsanitize-recover` isn't supported (yet).
https://developercommunity.visualstudio.com/t/add-fsanitize-recoveraddress-support-to-asan/1459414

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27404#discussion_r2365963166

From kbarrett at openjdk.org  Sun Sep 21 06:07:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 21 Sep 2025 06:07:18 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
In-Reply-To: <c275OWHpSAwbt8Y0Ls-LndHh9LaU-j3PhrUgABIV_gk=.9bfb6eb1-df52-4711-adb7-bc03ac337089@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
 <c275OWHpSAwbt8Y0Ls-LndHh9LaU-j3PhrUgABIV_gk=.9bfb6eb1-df52-4711-adb7-bc03ac337089@github.com>
Message-ID: <Pj6KKwi4riK_CnWTe3Odfulo5lHmoA-FO_HHaSuc_78=.913f10ef-7568-45c4-b7fb-be3ce5e7fae0@github.com>

On Sat, 20 Sep 2025 14:27:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi, jdk support address sanitizer and leak sanitizer for now. It seems that this PR only concern address sanitizer, does the leak sanitizer also need this enhancement

gcc15.2 docs list the sanitizers that support recovery, and "leak" is not in
that list. Sanitizers that support it enable recovery by default, except for
"address", which is noted as still being experimental (which is presumably why
it's not enabled by default).
https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Instrumentation-Options.html#index-fsanitize-recover
Once "address" is no longer experimental we can presumably remove the explicit
recovery enabling.

But maybe we should consider this PR premature, since `-fsanitize-recovery=address" is still experimental.

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3315527909

From kbarrett at openjdk.org  Sun Sep 21 06:07:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 21 Sep 2025 06:07:19 GMT
Subject: RFR: 8368176: ASAN should not inhibit hs-err file generation
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <pR1O-X1OQcoH-iY6ULgr7K0IDRCx5rOYzRWk2JNWZNc=.ad70e2f1-ffa4-44a7-b012-c5e2a1b75d69@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

Shouldn't there be a configure check for the availability of the `-fsanitize-recovery=address` option?

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3315528226

From mbaesken at openjdk.org  Mon Sep 22 07:03:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Sep 2025 07:03:17 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <gLaZrGgoJbk7_st5N8kR1vtHytGn_Mn8xDR5SmaS950=.a4df92f3-6b27-446c-9a13-226176eb9750@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

Hi Alexey, thanks for approving !

>  So let's wait for some feedback on libsyslookup .

Any updates on the libsyslookup topic ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3317248191

From mdoerr at openjdk.org  Mon Sep 22 09:28:52 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Sep 2025 09:28:52 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <BkK2R8rxY9PzEt72KHMr8DN95MVqkaAVJcGctyaMvVM=.6549f83d-e513-4485-bd76-c40b1fcbc9e5@github.com>
Message-ID: <mPWTkcvbSNSLyESDpLFdsdB4E9dFR-98qaDyAXcK1nI=.78780a4d-43d3-4987-b023-2db70a6c247c@github.com>

On Fri, 19 Sep 2025 09:09:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I've pinged Maurizio about libsyslookup; let's hear what he says first.

@JornVernee: You may also want to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3317784399

From mbaesken at openjdk.org  Mon Sep 22 12:45:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Sep 2025 12:45:40 GMT
Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk libs
Message-ID: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>

A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed.

libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD).
libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc;  however it might still be better to link $(LIBPTHREAD) in this special case.

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

Commit messages:
 - JDK-8368273

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

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

From erikj at openjdk.org  Mon Sep 22 13:15:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 13:15:45 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <3o-2PIm2_DydDWhRcbiPgVMZNC6WLeUDwV1IrnXZjBQ=.e0706448-5f17-46c7-962d-6a33f1c44298@github.com>

On Fri, 19 Sep 2025 16:43:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

make/common/native/Link.gmk line 66:

> 64:     SetSharedLibraryName = \
> 65:       -Wl,-soname=$1
> 66:   endif

Indentation looks off here.
Suggestion:

ifeq ($(call isCompiler, gcc), true)
  SetSharedLibraryName = \
      -Wl,-soname=$1
else ifeq ($(call isCompiler, clang), true)
  ifeq ($(call isTargetOs, macosx), true)
    SetSharedLibraryName = \
        -Wl,-install_name, at rpath/$1
  else ifeq ($(call isTargetOs, aix), true)
    SetSharedLibraryName =
  else
    # Default works for linux, might work on other platforms as well.
    SetSharedLibraryName = \
        -Wl,-soname=$1
  endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27394#discussion_r2368327647

From ihse at openjdk.org  Mon Sep 22 13:41:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 13:41:57 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk [v2]
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <He5S82QLPeoYHvEERoKTVIqULuVKIm_OiVBjL-qXpjA=.fe0e21c6-d753-42fc-a4a7-4a3e5935af0d@github.com>

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27394/files
  - new: https://git.openjdk.org/jdk/pull/27394/files/5a259541..812a6e53

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

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

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

From ihse at openjdk.org  Mon Sep 22 14:08:27 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 14:08:27 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk [v3]
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <CegqlFg9HeCwgJZ3n_jbm-WKWygBr-K70lbjwPOVxao=.85cc8adb-7205-4791-be61-bcea1e2a4f32@github.com>

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

Magnus Ihse Bursie 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 'master' into no-macros-in-spec
 - Fix indentation
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - 8368102: Don't store macros in spec.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27394/files
  - new: https://git.openjdk.org/jdk/pull/27394/files/812a6e53..33d252e6

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

  Stats: 108640 lines in 579 files changed: 104612 ins; 1687 del; 2341 mod
  Patch: https://git.openjdk.org/jdk/pull/27394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27394/head:pull/27394

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

From erikj at openjdk.org  Mon Sep 22 14:08:27 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 14:08:27 GMT
Subject: RFR: 8368102: Don't store macros in spec.gmk [v3]
In-Reply-To: <CegqlFg9HeCwgJZ3n_jbm-WKWygBr-K70lbjwPOVxao=.85cc8adb-7205-4791-be61-bcea1e2a4f32@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
 <CegqlFg9HeCwgJZ3n_jbm-WKWygBr-K70lbjwPOVxao=.85cc8adb-7205-4791-be61-bcea1e2a4f32@github.com>
Message-ID: <Kz95UGzujAjW8SxcOBSf5iUedW69LXa2C9feiyFnm3U=.508618a9-2d16-48f6-b54f-84d8568dafd8@github.com>

On Mon, 22 Sep 2025 14:05:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
>> 
>> We should move them to normal .gmk code, and rename them.
>> 
>> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.
>
> Magnus Ihse Bursie 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 'master' into no-macros-in-spec
>  - Fix indentation
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - 8368102: Don't store macros in spec.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27394#pullrequestreview-3252999579

From ihse at openjdk.org  Mon Sep 22 14:18:33 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 14:18:33 GMT
Subject: Integrated: 8368102: Don't store macros in spec.gmk
In-Reply-To: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
References: <uVkvDgJUIycB4WtkA0Ymd3pLN01oazenmVPLVltTVb0=.3e69e5be-0d5b-4bae-b537-916a93acddf2@github.com>
Message-ID: <nDMmwrltTVjuq_zmwmubDTHV1yFARa8rAolc9NLlq2w=.133b7571-5adc-47b8-8496-6c2ad8bc2946@github.com>

On Fri, 19 Sep 2025 16:43:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We currently have three macros (as in "functions", not just simple strings) that are assigned in spec.gmk. This is in contrast with the rest of the values assigned in spec.gmk, and it is surprising and is forcing an odd syntax. Furthermore, these macros are named as constants, and not as we normally name functions/macros.
> 
> We should move them to normal .gmk code, and rename them.
> 
> The three macros are `SET_SHARED_LIBRARY_ORIGIN`, `SET_EXECUTABLE_ORIGIN` and `SET_SHARED_LIBRARY_NAME`.

This pull request has now been integrated.

Changeset: 3c6ef5e2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c6ef5e27ae3585b48e9599020e4323bf9ed381e
Stats:     109 lines in 8 files changed: 61 ins; 40 del; 8 mod

8368102: Don't store macros in spec.gmk

Reviewed-by: erikj

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

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

From jvernee at openjdk.org  Mon Sep 22 15:06:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 22 Sep 2025 15:06:09 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs
In-Reply-To: <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
Message-ID: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>

On Fri, 19 Sep 2025 09:08:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  but it is not used

It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.

Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2368874988

From mbaesken at openjdk.org  Mon Sep 22 15:32:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 22 Sep 2025 15:32:27 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

  libsyslookup - bring back LIBDL (comment JornVernee)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27358/files
  - new: https://git.openjdk.org/jdk/pull/27358/files/7c102d5f..54c0339e

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

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

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

From mdoerr at openjdk.org  Mon Sep 22 15:45:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 Sep 2025 15:45:44 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
Message-ID: <Q7-drd7xo80YV7jKpuZCW6eDR2KgcPuPOchY5fi1Aa4=.f5fb5c35-6015-40d0-8133-dbe1366d7db1@github.com>

On Mon, 22 Sep 2025 15:32:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libsyslookup - bring back LIBDL (comment JornVernee)

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3253643189

From erikj at openjdk.org  Mon Sep 22 16:36:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 16:36:57 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
 <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
Message-ID: <fPcjhpd8fCqQXE1yQzBRGNLyBF1WRFxnECiFl2CB79Q=.92dcbd06-31c1-4f19-a5c3-ff67addee46d@github.com>

On Mon, 22 Sep 2025 15:00:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?
>
>>  but it is not used
> 
> It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.
> 
> Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library, to guarantee that `libdl` symbols will be findable.

These sounds convoluted enough to warrant a comment explaining this in the makefile to avoid accidents in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2369325183

From ihse at openjdk.org  Mon Sep 22 18:46:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 18:46:24 GMT
Subject: RFR: 8368312: Move CC_OUT_OPTION out of spec.gmk
Message-ID: <uyTydBFlDApGzrybDKQEJEUzDLq_CbYeJvFe-598IDY=.ea6303d5-8ab4-4b12-af49-431f131801b5@github.com>

The CC_OUT_OPTION is a bit tricky, since it tries to encode a literal space from configure. Fortunately, it is only used in a single place, so we can just define it in place instead.

This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

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

Commit messages:
 - Remove dangling else
 - 8368312: Move CC_OUT_OPTION out of spec.gmk

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

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

From erikj at openjdk.org  Mon Sep 22 18:51:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 18:51:10 GMT
Subject: RFR: 8368312: Move CC_OUT_OPTION out of spec.gmk
In-Reply-To: <uyTydBFlDApGzrybDKQEJEUzDLq_CbYeJvFe-598IDY=.ea6303d5-8ab4-4b12-af49-431f131801b5@github.com>
References: <uyTydBFlDApGzrybDKQEJEUzDLq_CbYeJvFe-598IDY=.ea6303d5-8ab4-4b12-af49-431f131801b5@github.com>
Message-ID: <UmTpVkIJiHTek6gRrd59pyHP9hwian7isqUdKlXjEWQ=.4d36d7ac-7f70-4c44-b603-13e4ca3b27ba@github.com>

On Mon, 22 Sep 2025 16:35:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The CC_OUT_OPTION is a bit tricky, since it tries to encode a literal space from configure. Fortunately, it is only used in a single place, so we can just define it in place instead.
> 
> This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27431#pullrequestreview-3254602379

From ihse at openjdk.org  Mon Sep 22 19:33:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 19:33:24 GMT
Subject: RFR: 8368326: Don't export unresolved make variables from configure
Message-ID: <sxJmCGwUpz33kqLuLMIMNGtFfhvJu-U4YLpQLDs8nQc=.6b5e4c37-c611-4df1-9d85-84ebaf20dbf6@github.com>

A few remaining variables in spec.gmk, like `BUILD_JDK`, is setup by configure to include makefile variables, like `$(JDK_OUTPUTDIR)`.

This makes reasoning about spec.gmk unnecessary complex. Instead, we should just expose simple, resolved text strings from configure. Any remaining logic is better expressed directly in the makefiles.

This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

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

Commit messages:
 - 8368326: Don't export unresolved make variables from configure

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

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

From ihse at openjdk.org  Mon Sep 22 21:06:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 21:06:51 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com>
 <kvOIwycuurywlFl3lK6AP9v8-asmWqweC-HAS6MUufM=.4bf691c5-d6c5-4107-8bbe-4736fd60730f@github.com>
 <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com>
 <5GdCr5pwjasY8bwW2GcWiOUUr2Rpv7-SbnMi4pU3VLo=.0c9c940d-7209-4e06-897c-bf9dba0bc486@github.com>
Message-ID: <TUcNVWuAvwAaqlG0qSMa5hLHFjJsJBvp5nWifsPHTbI=.b4197f75-078a-4789-b8e9-382394b44a75@github.com>

On Mon, 22 Sep 2025 15:00:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very  fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything?
>
>>  but it is not used
> 
> It is not used by the library itself, but we do dynamic `dlsym` calls on this library when a user tries to look up a symbol through `Linker.nativeLinker().defaultLookup().find(...)`. This is supposed to be able to find symbols from 'the standard library' which is an unspecified platform specific set of symbols. We link against `libdl` so that we can find symbols in that library as well (since `dlsym` recurses into a library's dependencies when looking up a symbol). We don't have a comprehensive test which tests that a certain set of symbols is available. Trying to look up a symbol from `libdl` might give a false positive if the symbol happens to be pulled in by another library that `libsyslookup` depends on, so testing this is unreliable.
> 
> Either way, I think we want to keep linking against `libdl` so that it keeps being a dependency of the `libsyslookup` library, to guarantee that `libdl` symbols will be findable.

@JornVernee Thanks! You confirmed basically what I suspected.

@MBaesken Can you revert your changes to `libsyslookup`, and add a comment summarizing Jorn's description above, that it is imperative that we keep linking with libdl even if it seems unused by the library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2370302658

From ihse at openjdk.org  Mon Sep 22 21:06:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 22 Sep 2025 21:06:54 GMT
Subject: Integrated: 8368312: Move CC_OUT_OPTION out of spec.gmk
In-Reply-To: <uyTydBFlDApGzrybDKQEJEUzDLq_CbYeJvFe-598IDY=.ea6303d5-8ab4-4b12-af49-431f131801b5@github.com>
References: <uyTydBFlDApGzrybDKQEJEUzDLq_CbYeJvFe-598IDY=.ea6303d5-8ab4-4b12-af49-431f131801b5@github.com>
Message-ID: <k72C-LwIJhT0Wna6YEz8khDcDObuR6fPd-ENVrLgpR4=.f7fac836-4b3b-4d2a-9f79-6680902c1c81@github.com>

On Mon, 22 Sep 2025 16:35:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The CC_OUT_OPTION is a bit tricky, since it tries to encode a literal space from configure. Fortunately, it is only used in a single place, so we can just define it in place instead.
> 
> This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

This pull request has now been integrated.

Changeset: d0fe8f7e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0fe8f7ede7c2426438c7d6dc5a24cfd2f1d094e
Stats:     19 lines in 4 files changed: 8 ins; 8 del; 3 mod

8368312: Move CC_OUT_OPTION out of spec.gmk

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Mon Sep 22 21:54:08 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 Sep 2025 21:54:08 GMT
Subject: RFR: 8368326: Don't export unresolved make variables from
 configure
In-Reply-To: <sxJmCGwUpz33kqLuLMIMNGtFfhvJu-U4YLpQLDs8nQc=.6b5e4c37-c611-4df1-9d85-84ebaf20dbf6@github.com>
References: <sxJmCGwUpz33kqLuLMIMNGtFfhvJu-U4YLpQLDs8nQc=.6b5e4c37-c611-4df1-9d85-84ebaf20dbf6@github.com>
Message-ID: <JV9jiS-JgxIb1LUC42Veb2dhmOAXx9_pI_WU-yuh8wc=.106e3ae6-c6e7-442e-8c11-664ba53388e4@github.com>

On Mon, 22 Sep 2025 18:41:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A few remaining variables in spec.gmk, like `BUILD_JDK`, is setup by configure to include makefile variables, like `$(JDK_OUTPUTDIR)`.
> 
> This makes reasoning about spec.gmk unnecessary complex. Instead, we should just expose simple, resolved text strings from configure. Any remaining logic is better expressed directly in the makefiles.
> 
> This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27435#pullrequestreview-3255297002

From mbaesken at openjdk.org  Tue Sep 23 08:10:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 08:10:03 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

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

  Add comment regarding LIBSYSLOOKUP and LIBDL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27358/files
  - new: https://git.openjdk.org/jdk/pull/27358/files/54c0339e..8d6fee5b

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

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

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

From mbaesken at openjdk.org  Tue Sep 23 08:10:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 08:10:04 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v2]
In-Reply-To: <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <iKMlhzx4soyoNMgxmjvW_KAsIDYwWHvJgTBiK5oq8HY=.f9a31950-a797-4721-820e-c01e28d99c0a@github.com>
Message-ID: <7c8YuMaalOW6frwsrdVM3C6EK2UAKHQpPDMUukqKhfo=.60750900-9cd1-46d9-97fe-abcef874edfb@github.com>

On Mon, 22 Sep 2025 15:32:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libsyslookup - bring back LIBDL (comment JornVernee)

I added a comment regarding LIBSYSLOOKUP / LIBDL .

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3322859888

From azafari at openjdk.org  Tue Sep 23 08:21:21 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 23 Sep 2025 08:21:21 GMT
Subject: RFR: 8368176: ASAN build should optionally not stop the JVM
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <t64kk6H_JAqsElGXhTibYhuXhCbfALJK-0yavCXomWI=.e18f5d5b-a800-4baf-b067-a3f6ae07f128@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

The logic behind the ASAN is that when an error is detected, the program is in an unstable state. So letting it to continue may produce more errors that more likely are caused by the first error. 
Instead of turning on/off the whole build/run of the program, we can skip/exclude the places (i.e., functions) that we don't want the ASAN reports (using ATTRIBUTE_NO_ASAN).

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3322900909

From stuefe at openjdk.org  Tue Sep 23 09:36:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Sep 2025 09:36:40 GMT
Subject: RFR: 8368176: ASAN build should optionally not stop the JVM
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <LMkHT0Ya6GNmA0cP8BzvS_Ujv1Dr5xv8eUby6j58xrA=.37b06fe8-7d18-458b-a559-a2aecacfac49@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

I found a better and more reliable way to get hs-err files with ASAN : https://github.com/openjdk/jdk/pull/27446. 

So for me, the main motivation for this change is gone, and I wonder whether I should just close this PR.

Only, I think it still worthwhile to have at least the option to continue running the JVM. Mostly because the new alternative proposal, albeit a lot better than this one, relies on the ability of installing ASAN callbacks, and not all ASAN versions may allow that.

@afshin-zafari 
> The logic behind the ASAN is that when an error is detected, the program is in an unstable state. So letting it to continue may produce more errors that more likely are caused by the first error.

I am aware of that, and count on that. Please see the motivation I gave in the description above. 

> Instead of turning on/off the whole build/run of the program, we can skip/exclude the places (i.e., functions) that we don't want the ASAN reports (using ATTRIBUTE_NO_ASAN).

That would not be very useful though: you would hide the error. I want to see the error. I just want the JVM to continue after that error report has been written to stderr.

@kimbarrett 
> But maybe we should consider this PR premature, since `-fsanitize-recovery=address" is still experimental.

I am pretty sure its experimental because there is no safe way in which the program could continue. So - the feature itself is stable, but the target program would be instable. I don't see what the disadvantage would be in allowing to do that, though. Whoever uses ASAN in a way like this must know what he is doing.

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3323150387

From aivanov at openjdk.org  Tue Sep 23 11:17:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Sep 2025 11:17:56 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <XFM7yly3EDiG3i3Z_pAHelxL8XI1my_uBlw2mu2DMrc=.7b2bb9e8-7cbc-419f-b985-66342e0815b8@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3257437167

From ihse at openjdk.org  Tue Sep 23 11:43:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 11:43:19 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

make/modules/java.base/Lib.gmk line 199:

> 197:       CXXFLAGS := -std=c++17, \
> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
> 199:       LIBS_linux := $(LIBDL) $(LIBM), \

You need to restore the libdl dependency as well, not just document why it's needed. ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372023487

From ihse at openjdk.org  Tue Sep 23 11:46:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 11:46:31 GMT
Subject: Integrated: 8368326: Don't export unresolved make variables from
 configure
In-Reply-To: <sxJmCGwUpz33kqLuLMIMNGtFfhvJu-U4YLpQLDs8nQc=.6b5e4c37-c611-4df1-9d85-84ebaf20dbf6@github.com>
References: <sxJmCGwUpz33kqLuLMIMNGtFfhvJu-U4YLpQLDs8nQc=.6b5e4c37-c611-4df1-9d85-84ebaf20dbf6@github.com>
Message-ID: <MyytskaF-1p0YWrvc7yjyPRyBkkI90NZTnkOmLD_2CA=.89d71f43-7b91-436f-b710-0df0b43dd498@github.com>

On Mon, 22 Sep 2025 18:41:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A few remaining variables in spec.gmk, like `BUILD_JDK`, is setup by configure to include makefile variables, like `$(JDK_OUTPUTDIR)`.
> 
> This makes reasoning about spec.gmk unnecessary complex. Instead, we should just expose simple, resolved text strings from configure. Any remaining logic is better expressed directly in the makefiles.
> 
> This is part of an effort to clean up spec.gmk to not contain so much weird stuff.

This pull request has now been integrated.

Changeset: dbf787c6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbf787c6b78669c69402d2a57d1ec462035d54c4
Stats:     54 lines in 2 files changed: 16 ins; 29 del; 9 mod

8368326: Don't export unresolved make variables from configure

Reviewed-by: erikj

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

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

From mbaesken at openjdk.org  Tue Sep 23 11:56:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 11:56:49 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
 <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
Message-ID: <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>

On Tue, 23 Sep 2025 11:40:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment regarding LIBSYSLOOKUP and LIBDL
>
> make/modules/java.base/Lib.gmk line 199:
> 
>> 197:       CXXFLAGS := -std=c++17, \
>> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
>> 199:       LIBS_linux := $(LIBDL) $(LIBM), \
> 
> You need to restore the libdl dependency as well, not just document why it's needed. ;-)

That's another build  ( BUILD_LIBSIMD_SORT ). Not our special  one (syslookup).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372055345

From aivanov at openjdk.org  Tue Sep 23 12:34:46 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Sep 2025 12:34:46 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
 <dkLp41QrXmZs4ZEbcm9TG7YKYqdOXk76uPBaiwWGe-M=.2d4de0e9-57c2-4c8a-a267-e3089a8cc749@github.com>
 <7Jh6JTRECBsbB03-JqBSP8CkoFVNUnoPjdXUdtxFNaw=.9e01fbff-483f-4c3b-adb1-a5d050744b6a@github.com>
Message-ID: <QqfdUOiga612AGpZNhc6bJZgiOIRHd-8Sm7UbC-nFVw=.842408aa-1ab7-4e42-a981-08aa5dcfcca1@github.com>

On Tue, 23 Sep 2025 11:53:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 199:
>> 
>>> 197:       CXXFLAGS := -std=c++17, \
>>> 198:       DISABLED_WARNINGS_gcc := unused-variable, \
>>> 199:       LIBS_linux := $(LIBDL) $(LIBM), \
>> 
>> You need to restore the libdl dependency as well, not just document why it's needed. ;-)
>
> That's another build  ( BUILD_LIBSIMD_SORT ). Not our special  one (syslookup).

Yes, it looks confusing in the diffs. You have to expand the unchanged lines to see it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2372166387

From ihse at openjdk.org  Tue Sep 23 13:53:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 13:53:15 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <8azN1bEI1nk3bHz_5oaNXn48qJ9oYiTRl870YXy3yT8=.345c467e-9f9a-448b-ab75-5ae8c2df1770@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

I see. Sorry I misread. Then this looks good!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3258138148

From ihse at openjdk.org  Tue Sep 23 14:04:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 14:04:17 GMT
Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk
 libs
In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
Message-ID: <LOSWRxE8w0xqlN33tM8HZiAT7_jEFG391-Bsv9xUNss=.cd3cf242-b9d2-42fe-89ad-9baeb57a7273@github.com>

On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed.
> 
> libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD).
> libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc;  however it might still be better to link $(LIBPTHREAD) in this special case.

Looks good!

I agree that it is better to keep libpthread for libawt_xawt.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27426#pullrequestreview-3258186230

From ihse at openjdk.org  Tue Sep 23 14:22:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 14:22:44 GMT
Subject: RFR: 8368176: ASAN build should optionally not stop the JVM
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <ah6r30pYK1_JFMi3odhiGsHTVG-pe3wiRLmOcxBiM6I=.d3a057ac-58b4-495d-9c21-34fba02db185@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

> I found a better and more reliable way to get hs-err files with ASAN : #27446.
> 
> So for me, the main motivation for this change is gone, and I wonder whether I should just close this PR.

Yes, I think you should. As you say, JBS-8368365 is a much better solution. This is just shaky ground; if we had no other options we might have considered it, but now there seem to be no good reason.

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3324231212

From stuefe at openjdk.org  Tue Sep 23 14:27:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Sep 2025 14:27:53 GMT
Subject: RFR: 8368176: ASAN build should optionally not stop the JVM
In-Reply-To: <ah6r30pYK1_JFMi3odhiGsHTVG-pe3wiRLmOcxBiM6I=.d3a057ac-58b4-495d-9c21-34fba02db185@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
 <ah6r30pYK1_JFMi3odhiGsHTVG-pe3wiRLmOcxBiM6I=.d3a057ac-58b4-495d-9c21-34fba02db185@github.com>
Message-ID: <3-h-jF_IPeGvrOHT_fRaDSKWCstWwtC8ZD-FeiSLiHg=.35a3bdbd-dec7-498a-a8c5-e8de0ee631a0@github.com>

On Tue, 23 Sep 2025 14:20:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I found a better and more reliable way to get hs-err files with ASAN : #27446.
> > So for me, the main motivation for this change is gone, and I wonder whether I should just close this PR.
> 
> Yes, I think you should. As you say, JBS-8368365 is a much better solution. This is just shaky ground; if we had no other options we might have considered it, but now there seem to be no good reason.

Okay then! I'll close this as wont fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27404#issuecomment-3324261847

From stuefe at openjdk.org  Tue Sep 23 14:27:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Sep 2025 14:27:54 GMT
Subject: Withdrawn: 8368176: ASAN build should optionally not stop the JVM
In-Reply-To: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
References: <qz22QPhHp5ttixms8PJwwCgcLLvkDMHsEiwVHH4AwFw=.9a759404-9cff-4ceb-affb-ee1200d46085@github.com>
Message-ID: <-MDXc33LawxZIp-DpsL9XqZVVME8ZqBKblULcDdQAoQ=.d2b148fa-900f-4e9a-8bf9-a648b52ec005@github.com>

On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ASAN, when catching an error, will abort the process.
> 
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp. `-fno-sanitize-recover=address`. This controls whether, once ASAN returns from its error report, the compiler-generated ASAN stubs will abort the process. This is by default set to `-fno-sanitize-recover=address`, so we won't recover.
> 2) The runtime option `halt_on_error` controls whether ASAN itself returns from its error handler or whether it aborts the process. This, by default, is set to `1`, so by default ASAN aborts.
> 
> We "double abort" in the sense that two options are overlaid and both prevent the process from continuing.
> 
> I propose that we set, during build time for ASAN builds, the option `-fsanitize-recover=address`. Now, we can control whether to abort or not using the runtime setting `halt_on_error=0`. By default, we still will abort, since `halt_on_error=1`. So, the default behavior won't change. However, we can now at least decide to do it differently.
> 
> What would that give us?
> 
> By aborting right away, ASAN denies the JVM the option to catch the error and write an hs-err file. Of course, not every error that ASAN catches will result in a segfault or in an assertion. The JVM could lurch on for a bit before it stumbles. However, the chance for the JVM to stop on its own very soon after a memory corruption happens is pretty good. Then we get a hs-err file and a crash dump in close correlation to the error ASAN caught.
> 
> And even if there is no close relationship between the original ASAN error and the eventual segfault/assertion (think ASAN sees a double free, JVM continues, and after a while asserts somewhere else as a remote consequence of the error - the stacks in the hs-err file won't be related to the original error) - the hs-err file is shock-full of helpful information about running threads (see also [JDK-8368124](https://bugs.openjdk.org/browse/JDK-8368124)), memory mappings, JVM flags, etc. All of that would make it easier to understand the ASAN report.
> 
> And even if the JVM survives, one can still attach to the still living process and grab thread dumps, VM.info reports, heap dumps etc.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Tue Sep 23 14:48:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Sep 2025 14:48:36 GMT
Subject: RFR: 8368468: Split out everything but configure results from spec.gmk
Message-ID: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>

Most of spec.gmk contains lines on the form:

VAR := @VAR@

which are setup using `AC_SUBST(VAR)` in the configure script. However, there are also some other stuff there, which are mostly put there since we had no other good place to do so.

I have now created a new file, `CommonVars.gmk`, which is automatically included, and moved everything but pure configure assignments from `spec.gmk` into this file.

That makes `spec.gmk` a great interface between configure and make -- the job of configure is to fill in `spec.gmk`, plain and simple.

This refactoring also points to additional future improvements, e.g. generating `spec.gmk` automatically from all `AC_SUBST` statements, and to clean up the new `CommonVars.gmk`. Right now I kept all lines in the same order as they appeared in `spec.gmk.template`, to minimize risk of unintentional changes (we have some non-`:=` assignments), and to facilitate comparison for this patch. It is also clear that we have room for improvement in how we do bootcycle-builds and build the build-jdk. My current solution is to keep the special spec files, even if they just set a single special flag, to minimize impact of this patch.

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

Commit messages:
 - 8368468: Split out everything but configure results from spec.gmk

Changes: https://git.openjdk.org/jdk/pull/27452/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368468
  Stats: 941 lines in 12 files changed: 475 ins; 413 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/27452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27452/head:pull/27452

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

From mbaesken at openjdk.org  Tue Sep 23 15:11:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 15:11:21 GMT
Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk
 libs [v3]
In-Reply-To: <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
 <fdlFhq7vRKLhq6Nv1WgC19xKC3bJs9hfakxSSfFHGbo=.297f8a40-f67e-4e61-90ad-19cfa97a8f2b@github.com>
Message-ID: <UAYCfIkXY99Mb2oyr4ztXqynDKGpuGFzl9ExQHc0yeA=.e1207a76-7e41-4c48-9c1a-22ec8913f66e@github.com>

On Tue, 23 Sep 2025 08:10:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment regarding LIBSYSLOOKUP and LIBDL

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3324427355

From mbaesken at openjdk.org  Tue Sep 23 15:11:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 Sep 2025 15:11:23 GMT
Subject: Integrated: 8367913: LIBDL dependency seems to be not needed for some
 jdk libs
In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com>
Message-ID: <Jw7Km9oN3MbAHvBlnNAThYtpWNqnSPmP23fhzFYfEoU=.081728e2-da25-49db-9b1f-32071566f79e@github.com>

On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it.

This pull request has now been integrated.

Changeset: 82bdef16
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82bdef16390deaa6863cdf8ecf26e6e99f6cb0a2
Stats:     7 lines in 3 files changed: 2 ins; 2 del; 3 mod

8367913: LIBDL dependency seems to be not needed for some jdk libs

Reviewed-by: aivanov, ihse, clanger, mdoerr

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

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

From erikj at openjdk.org  Tue Sep 23 17:41:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 Sep 2025 17:41:03 GMT
Subject: RFR: 8368468: Split out everything but configure results from
 spec.gmk
In-Reply-To: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
Message-ID: <7dMRpo7dGGmy9-eTPPbP5UKvW7cBy8e_A0yYzlfVER0=.2071c4cd-7a7b-493d-990f-d7c41aadb803@github.com>

On Tue, 23 Sep 2025 13:48:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Most of spec.gmk contains lines on the form:
> 
> VAR := @VAR@
> 
> which are setup using `AC_SUBST(VAR)` in the configure script. However, there are also some other stuff there, which are mostly put there since we had no other good place to do so.
> 
> I have now created a new file, `CommonVars.gmk`, which is automatically included, and moved everything but pure configure assignments from `spec.gmk` into this file.
> 
> That makes `spec.gmk` a great interface between configure and make -- the job of configure is to fill in `spec.gmk`, plain and simple.
> 
> This refactoring also points to additional future improvements, e.g. generating `spec.gmk` automatically from all `AC_SUBST` statements, and to clean up the new `CommonVars.gmk`. Right now I kept all lines in the same order as they appeared in `spec.gmk.template`, to minimize risk of unintentional changes (we have some non-`:=` assignments), and to facilitate comparison for this patch. It is also clear that we have room for improvement in how we do bootcycle-builds and build the build-jdk. My current solution is to keep the special spec files, even if they just set a single special flag, to minimize impact of this patch.

Marked as reviewed by erikj (Reviewer).

make/common/CommonVars.gmk line 222:

> 220: 
> 221: # You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java $(NEW_JAVAC) ...
> 222: # Use = assignment to be able to override in bootcycle-spec.gmk

This comment isn't correct anymore.

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

PR Review: https://git.openjdk.org/jdk/pull/27452#pullrequestreview-3259014444
PR Review Comment: https://git.openjdk.org/jdk/pull/27452#discussion_r2373028906

From acobbs at openjdk.org  Tue Sep 23 18:06:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 18:06:32 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <P1UPwF03g50bB2GIDqYTjZFWjuG_VRzZZrXf_mkALzY=.d7a8cff5-c571-441e-b14d-ba90aec7311e@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Bumping up the reviewer count to ensure someone from the compiler group approves.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325033159

From prappo at openjdk.org  Tue Sep 23 21:04:59 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 21:04:59 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>

On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Hi Archie. I've just seen this PR. It looks nice.

While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.

IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325540024

From acobbs at openjdk.org  Tue Sep 23 21:23:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 21:23:47 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
Message-ID: <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>

On Tue, 23 Sep 2025 21:02:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.

FWIW there is a discussion thread (starting [here](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html)), but it's been on/off since November 2024.

> IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?

Astute question :) In general, it's completely up to the particular warning. The scope can even extend _before_ the annotation; this is the case with `"dangling-doc-comments"` (see #24600). But normally the "scope" of a declaration includes any annotations on that declaration, simply because the start position of the declaration includes them (the annotations are part of the declaration, not a separate prior thing).

Regarding exactly how "it's completely up to the particular warning": Since #26138, the `DiagnosticPosition` class now has a `getLintPosition()` property. This allows the caller to specify any arbitrary source code position at which to define which `@SuppressWarnings` annotations apply to the warning. Search for `withLintPosition()` to see a couple of uses of it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325592697

From prappo at openjdk.org  Tue Sep 23 21:27:56 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 21:27:56 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
Message-ID: <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>

On Tue, 23 Sep 2025 21:20:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > While I've read the CSR, I haven't read any compiler-dev thread(s). At least not carefully. I also haven't seen the diff.
> 
> FWIW there is a discussion thread (starting [here](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html)), but it's been on/off since November 2024.
> 
> > IIUC, this annotation can be applied to itself: `@SupressWarnings("suppression")`. Has the scope of `@SupressWarnings` always included the annotation itself, or it's something that you had to tweak in this PR?
> 
> Astute question :) In general, it's completely up to the particular warning. The scope can even extend _before_ the annotation; this is the case with `"dangling-doc-comments"` (see #24600). But normally the "scope" of a declaration includes any annotations on that declaration, simply because the start position of the declaration includes them (the annotations are part of the declaration, not a separate prior thing).
> 
> Regarding exactly how "it's completely up to the particular warning": Since #26138, the `DiagnosticPosition` class now has a `getLintPosition()` property. This allows the caller to specify any arbitrary source code position at which to define which `@SuppressWarnings` annotations apply to the warning. Search for `withLintPosition()` to see a couple of uses of it.

The reason I ask is that I can probably see how it could be useful to emit a "suppression" warning from this:

    @SuppressWarnings("suppression")
    public class A { }

I'm not suggesting the PR should implement it, I'm just thinking aloud.

I realise that if it were to implement the annotation as non-self-referring, then there would need to be a way to suppress it too, however silly it may sound.

IIRC there's no way to apply a meta annotation on a _call site_. Even if `@SuppressWarnings` was a `@Repeatable` annotation, this would not have the desired effect:

    @SuppressWarnings("suppression")
    @SuppressWarnings("suppression")
    public void foo(String bar) { ...

Another option is to go one scope higher and put an annotation there:

    @SuppressWarnings("suppression")
    public class FooBar { ...
    
        @SuppressWarnings("suppression")
        public void foo(String bar) { ...

The problem is that you may not have a higher scope. Which sounds like a rare, uninteresting corner case.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325606585

From acobbs at openjdk.org  Tue Sep 23 21:52:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Sep 2025 21:52:26 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
Message-ID: <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>

On Tue, 23 Sep 2025 21:25:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> The reason I ask is that I can probably see how it could be useful to emit a "suppression" warning from this:

It's a reasonable option to consider. I think the main worry is that it could complicate build situations where the same code was being compiled with `-Werror` under two different compiler versions. Suppose you had code like this:

method m() {
   // warning here
}

that generated a `"foo"` warning in JDK N but not JDK M. So you do this:

@SuppressWarnings("foo")
method m() {
  // warning here
}

OK, now you get a `"suppression"` warning in JDK M but not JDK N. So next you do this:

@SuppressWarnings({ "foo", "suppression" })
method m() {
  // warning here
}

Oops! Now you get a `"suppression"` warning in JDK N.

Then the only way out would be `-Xlint:-suppression`, which means the feature has caused a wild goose chase and is being somewhat self-defeating.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325659614

From prappo at openjdk.org  Tue Sep 23 22:28:37 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 23 Sep 2025 22:28:37 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
Message-ID: <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>

On Tue, 23 Sep 2025 21:49:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Oops! Now you get a `"suppression"` warning in JDK N.

Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.

I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarning` in any of the _child scopes_. Note, not just ineffective `@SuppressWarning`s, but none at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3325741752

From mbaesken at openjdk.org  Wed Sep 24 13:10:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 Sep 2025 13:10:39 GMT
Subject: Integrated: 8368273: LIBPTHREAD dependency is not needed for some jdk
 libs
In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
Message-ID: <xVMMdw03jE0d5hMJ6BWWfcmsx4NlXuWF57DZW0z1_wI=.511ddadf-9398-46f8-be04-f26c2f852d96@github.com>

On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed.
> 
> libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD).
> libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc;  however it might still be better to link $(LIBPTHREAD) in this special case.

This pull request has now been integrated.

Changeset: 0a64358a
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a64358aa82930e2bd323fcec2c1cb269ee200e0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368273: LIBPTHREAD dependency is not needed for some jdk libs

Reviewed-by: ihse

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

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

From mbaesken at openjdk.org  Wed Sep 24 13:10:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 Sep 2025 13:10:37 GMT
Subject: RFR: 8368273: LIBPTHREAD dependency is not needed for some jdk
 libs
In-Reply-To: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
References: <9rqfmYPQ3iJxOsPGd82m8E0VlT9XpKahJ51t6UhpQiQ=.c6564e78-669c-490c-8c9c-f3e4f9c39a9a@github.com>
Message-ID: <uLODBKwLl5Xn_0EXaDTlYmLbehGhAdK94zFZh934zBM=.87fb2aae-18a9-49f6-912b-dc51b84f4c56@github.com>

On Mon, 22 Sep 2025 12:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of JDK native libs link to $(LIBPTHREAD) but the dependency is not needed.
> 
> libsctp has no `pthread*` calls so most likely we can omit $(LIBPTHREAD).
> libawt_xawt only uses `pthread_self()` ; so on Linux it links without adding $(LIBPTHREAD) because it then uses `pthread_self() `from glibc;  however it might still be better to link $(LIBPTHREAD) in this special case.

Hi Magnus, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/27426#issuecomment-3328331208

From jkern at openjdk.org  Wed Sep 24 13:29:31 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 24 Sep 2025 13:29:31 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up
 of JDK-8354686)
Message-ID: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>

After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.

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

Commit messages:
 - JDK-8368250

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

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

From ihse at openjdk.org  Wed Sep 24 14:57:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Sep 2025 14:57:40 GMT
Subject: RFR: 8368468: Split out everything but configure results from
 spec.gmk [v2]
In-Reply-To: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
Message-ID: <judbzoNUpDEplqFeQsGc-uFFQTtCNAGrtu3cKmqyG_o=.342f5680-c137-47b6-bf97-c63adf0ad489@github.com>

> Most of spec.gmk contains lines on the form:
> 
> VAR := @VAR@
> 
> which are setup using `AC_SUBST(VAR)` in the configure script. However, there are also some other stuff there, which are mostly put there since we had no other good place to do so.
> 
> I have now created a new file, `CommonVars.gmk`, which is automatically included, and moved everything but pure configure assignments from `spec.gmk` into this file.
> 
> That makes `spec.gmk` a great interface between configure and make -- the job of configure is to fill in `spec.gmk`, plain and simple.
> 
> This refactoring also points to additional future improvements, e.g. generating `spec.gmk` automatically from all `AC_SUBST` statements, and to clean up the new `CommonVars.gmk`. Right now I kept all lines in the same order as they appeared in `spec.gmk.template`, to minimize risk of unintentional changes (we have some non-`:=` assignments), and to facilitate comparison for this patch. It is also clear that we have room for improvement in how we do bootcycle-builds and build the build-jdk. My current solution is to keep the special spec files, even if they just set a single special flag, to minimize impact of this patch.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment and remove dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27452/files
  - new: https://git.openjdk.org/jdk/pull/27452/files/96cb18e3..91b24f8e

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

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

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

From ihse at openjdk.org  Wed Sep 24 14:57:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Sep 2025 14:57:41 GMT
Subject: RFR: 8368468: Split out everything but configure results from
 spec.gmk [v2]
In-Reply-To: <7dMRpo7dGGmy9-eTPPbP5UKvW7cBy8e_A0yYzlfVER0=.2071c4cd-7a7b-493d-990f-d7c41aadb803@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
 <7dMRpo7dGGmy9-eTPPbP5UKvW7cBy8e_A0yYzlfVER0=.2071c4cd-7a7b-493d-990f-d7c41aadb803@github.com>
Message-ID: <2Q5PpwofvoFbtGGmvpwZO0GRpdsinjyFjx7Rcxavs68=.34f643f4-7c13-45c5-bf7e-7753585d7056@github.com>

On Tue, 23 Sep 2025 17:36:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment and remove dead code
>
> make/common/CommonVars.gmk line 222:
> 
>> 220: 
>> 221: # You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java $(NEW_JAVAC) ...
>> 222: # Use = assignment to be able to override in bootcycle-spec.gmk
> 
> This comment isn't correct anymore.

There were many issues here. First of all, NEW_JAVAC is not used anymore so it is dead code. Secondly, we still need = assignment for bootcycle builds, but only for JAVADOC. But this is not technically done in bootcycle-spec.gmk anymore. 

I removed the dead code and updated the comment, hope you are okay with it.

There's a lot of cleaning work needed for this file. At this point, I just wanted to do a clear a separation as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27452#discussion_r2376081463

From acobbs at openjdk.org  Wed Sep 24 15:02:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Sep 2025 15:02:02 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
Message-ID: <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>

On Tue, 23 Sep 2025 22:26:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.

Credit goes to @jddarcy for pinpointing those possible traps.

> I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarnings` in any of the _child scopes_. Note, not just ineffective `@SuppressWarnings`s, but none at all.

Here's an analogy that helps me justify the current design, fwiw. Have you ever been to New York or another city and walked by an otherwise completely blank wall that has "POST NO BILLS" signs stuck to it, and then thought about how ironic it is that posting bills is required in order to notify people not to post bills?

Sticking `@SuppressWarnings("suppression")` on a declaration is analogous. We're posting a notification not to do something, even though the notification itself risks doing it. But that's OK and we make a special exception for it.

If we didn't make such exceptions, then when you walked by such a wall you'd see a workman repeatedly posting and unposting the "POST NO BILLS" bills :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329111827

From mbaesken at openjdk.org  Wed Sep 24 15:36:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 Sep 2025 15:36:32 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt
Message-ID: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>

We have a legacy dependency of libjvm to librt for the` clock_*` functions :
https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139

But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.

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

Commit messages:
 - JDK-8368565

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

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

From prappo at openjdk.org  Wed Sep 24 16:36:32 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 24 Sep 2025 16:36:32 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
Message-ID: <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>

On Wed, 24 Sep 2025 14:58:38 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Thanks for this explanation. I can now see what you mean in the _Different Compiler Versions_ section of the CSR. That's some quality reasoning and future-proofing.
> 
> Credit goes to @jddarcy for pinpointing those possible traps.
> 
> > I suppose, it would unnecessarily complicate the design if we stipulate that `@SuppressWarnings("suppression")` should only emit a warning if there are no `@SuppressWarnings` in any of the _child scopes_. Note, not just ineffective `@SuppressWarnings`s, but none at all.
> 
> Here's an analogy that helps me justify the current design, fwiw. Have you ever been to New York or another city and walked by an otherwise completely blank wall that has "POST NO BILLS" signs stuck to it, and then thought about how ironic it is that posting bills is required in order to notify people not to post bills?
> 
> Sticking `@SuppressWarnings("suppression")` on a declaration is analogous. We're posting a notification not to do something, even though the notification itself risks doing it. But that's OK and we make a special exception for it.
> 
> If we didn't make such exceptions, then when you walked by such a wall you'd see a workman repeatedly posting and unposting the "POST NO BILLS" bills :)

That analogy is amusing, but it either barely applies here, or I'm too tired to see how it does.

In my most recent message, I mused about this: _what if `@SuppressWarnings("suppression")` were to emit a warning only if there's no `@SuppressWarnings` of any kind anywhere under it?_ This behaviour is minimally stricter than that of this PR, and is compatible with the M-N-compiler use case.

Basically, if `@SuppressWarnings("suppression")` was accidentally left with no suppressions under it, the compiler would warn you, so you could remove it. Because what's the reason for `@SuppressWarnings("suppression")` whose scope contains no suppressions?

Just to clarify, here's an example of what I mean:

    @SuppressWarnings("suppression")
    public void m() {
        /* a method that contains no @SuppressWarnings
           annotations whatsoever */
    }

Here's an example of what I **don't** mean:

    @SuppressWarnings("suppression")
    public void m() {
        /* a method that only contains @SuppressWarnings
           annotations that are ineffective. That is,
           annotations, that if removed, would __not__
           break compilation with -Werror */
    }

The idea here is to minimise the chance of `@SuppressWarnings("suppression")` becoming part of the furniture and hiding unneeded future suppressions. But maybe changing the behaviour as described above would introduce more complexity and future issues than it would catch potential bugs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329793388

From acobbs at openjdk.org  Wed Sep 24 16:48:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Sep 2025 16:48:58 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
 <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
Message-ID: <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>

On Wed, 24 Sep 2025 16:33:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Basically, if `@SuppressWarnings("suppression")` was accidentally left with no suppressions under it, the compiler would warn you, so you could remove it. Because what's the reason for `@SuppressWarnings("suppression")` whose scope contains no suppressions?

Sorry I didn't address this question before - but yes, this is a reasonable ida. It would basically be adding an exception to the exception. So, a bit of additional complexity but for a worthwhile cause. To stretch the analogy, it would be like making the observation: "If the area of the wall is zero, then you never need to post a "POST NO BILLS" bill on it".

I can think of one possible wrinkle though: warnings can actually be suppressed in the source code in two ways, by `@SuppressWarnings` and by `@Deprecated`  (see `Lint.suppressionsFrom(Symbol)`). So you'd also have to look for `@Deprecated`; but this also brings up the unsettling possibility that in the future, some new annotation might have a similar side-effect, and then we'd be in trouble again. So there is an aspect of this idea that requires us to make certain predictions about the future, which of course is dangerous. I think it's safer to "just say no".

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3329828755

From tanksherman27 at gmail.com  Wed Sep 24 17:08:34 2025
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 25 Sep 2025 01:08:34 +0800
Subject: Problems with LTO for HotSpot
Message-ID: <CAP2b4GMgjvJZt1a_tqZR2UNLkqZ-OZORgTOdeAoyW9n2aowg1g@mail.gmail.com>

Hi all,

Recently I've been picking up and resuming work on making LTO viable
for HotSpot. The aim is to have LTO as a working option available so
the benefits of enhanced optimization can be enjoyed by running Java
code, though making LTO the default is not really a goal, at least not
yet. The work has been going on decently well so far, but while
working on it, there have been 2 rather longstanding problems I
haven't really been able to solve. The first is related to
https://github.com/openjdk/jdk/pull/22864 switching
os::current_stack_pointer() to using runtime assembly, but we can
visit that later. The bigger issue is related to the flatten attribute
on the gcc compiler. In short, some G1 code (More specifically void
G1ParScanThreadState::trim_queue_to_threshold(uint threshold), void
G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet*
task_queues) and oop
G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr
region_attr, oop old, markWord old_mark)) is marked as flatten, which
causes gcc to inline all calls inside those methods. This normally
would be fine since the compilation unit boundary prevents inlining
from across source files, but when LTO is active, the method bodies
from other compilation units become available, and gcc then goes on a
rampage, mass inlining everything it can find until there is nothing
left to inline. On top of causing the JVM inflate to at least 60MB in
the best case, it also causes build problems, notably JDK-8343698 and
(suspected) JDK-8334616 and in general LTO is extremely slow, likely
due to this problem. It would seem that we'd need to create NOINLINE
wrappers for methods which are called by the flattened code but are
not defined in the same source file (g1ParScanThreadState.cpp).

Problematically however, the call hierarchy for these 3 methods is
downright *massive* since these methods are absolute monsters. This
makes trying to find which methods these 3 call very tedious and error
prone. After months and many different approaches, all of which have
failed, I'm still no closer to finding out which code needs NOINLINE
wrappers to prevent cross compilation unit inlining. Might there be a
better way to figure out which methods are called from outside the
g1ParScanThreadState.cpp source file than my current approach of
manually looking through an IDE (Since all automated tools have failed
in one way or another)? This is a very big blocker for working LTO
with HotSpot, once I manage to get this and the stack pointer issue
solved I believe I'll (hopefully) be able to get working LTO into the
JDK soon.

best regards,
Julian

From aph-open at littlepinkcloud.com  Wed Sep 24 17:20:36 2025
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 24 Sep 2025 18:20:36 +0100
Subject: Problems with LTO for HotSpot
In-Reply-To: <CAP2b4GMgjvJZt1a_tqZR2UNLkqZ-OZORgTOdeAoyW9n2aowg1g@mail.gmail.com>
References: <CAP2b4GMgjvJZt1a_tqZR2UNLkqZ-OZORgTOdeAoyW9n2aowg1g@mail.gmail.com>
Message-ID: <683a3aaf-e487-4906-bcb3-58cb8d971884@littlepinkcloud.com>

On 24/09/2025 18:08, Julian Waters wrote:
> This is a very big blocker for working LTO
> with HotSpot, once I manage to get this and the stack pointer issue
> solved I believe I'll (hopefully) be able to get working LTO into the
> JDK soon.

Isn't this really a failure of GCC's LTO heuristics? Surely it shouldn't 
do this.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From erikj at openjdk.org  Wed Sep 24 18:18:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 Sep 2025 18:18:55 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686)
In-Reply-To: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
Message-ID: <YoNQAzbZrkUe_wvbksezxeLWzG_sw6HI84aVwSzOBP0=.e7c957e4-9cd8-46a3-8cad-533f1ad6f46c@github.com>

On Wed, 24 Sep 2025 13:23:00 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.

make/autoconf/jdk-options.m4 line 570:

> 568:   # In the ubsan case we have to link every binary with the C++-compiler as linker, because inherently
> 569:   # the C-Compiler and the C++-compiler used as linker provide a different set of ubsan exports.
> 570:   # Linkung an executable with the C-compiler and one of its shared libraries with the C++-compiler

Suggestion:

  # Linking an executable with the C-compiler and one of its shared libraries with the C++-compiler

make/autoconf/jdk-options.m4 line 575:

> 573:       UBSAN_CFLAGS="$UBSAN_CFLAGS -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer"
> 574:       UBSAN_LDFLAGS="$UBSAN_LDFLAGS -Wl,-bbigtoc"
> 575:       LD="$LDCXX"

Indentation for blocks should be 2 spaces. https://openjdk.org/groups/build/doc/code-conventions.html
Suggestion:

    UBSAN_CFLAGS="$UBSAN_CFLAGS -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer"
    UBSAN_LDFLAGS="$UBSAN_LDFLAGS -Wl,-bbigtoc"
    LD="$LDCXX"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27468#discussion_r2376669448
PR Review Comment: https://git.openjdk.org/jdk/pull/27468#discussion_r2376675889

From erikj at openjdk.org  Wed Sep 24 18:22:59 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 Sep 2025 18:22:59 GMT
Subject: RFR: 8368468: Split out everything but configure results from
 spec.gmk [v2]
In-Reply-To: <judbzoNUpDEplqFeQsGc-uFFQTtCNAGrtu3cKmqyG_o=.342f5680-c137-47b6-bf97-c63adf0ad489@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
 <judbzoNUpDEplqFeQsGc-uFFQTtCNAGrtu3cKmqyG_o=.342f5680-c137-47b6-bf97-c63adf0ad489@github.com>
Message-ID: <rZvkRikmAa2bAmM7PCp-_nHK4rpGWMEb0_zVFr6NK80=.d21ad9f5-4011-4d78-9cbc-a4eacb050cb8@github.com>

On Wed, 24 Sep 2025 14:57:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of spec.gmk contains lines on the form:
>> 
>> VAR := @VAR@
>> 
>> which are setup using `AC_SUBST(VAR)` in the configure script. However, there are also some other stuff there, which are mostly put there since we had no other good place to do so.
>> 
>> I have now created a new file, `CommonVars.gmk`, which is automatically included, and moved everything but pure configure assignments from `spec.gmk` into this file.
>> 
>> That makes `spec.gmk` a great interface between configure and make -- the job of configure is to fill in `spec.gmk`, plain and simple.
>> 
>> This refactoring also points to additional future improvements, e.g. generating `spec.gmk` automatically from all `AC_SUBST` statements, and to clean up the new `CommonVars.gmk`. Right now I kept all lines in the same order as they appeared in `spec.gmk.template`, to minimize risk of unintentional changes (we have some non-`:=` assignments), and to facilitate comparison for this patch. It is also clear that we have room for improvement in how we do bootcycle-builds and build the build-jdk. My current solution is to keep the special spec files, even if they just set a single special flag, to minimize impact of this patch.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment and remove dead code

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27452#pullrequestreview-3264149118

From erikj at openjdk.org  Wed Sep 24 18:23:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 Sep 2025 18:23:01 GMT
Subject: RFR: 8368468: Split out everything but configure results from
 spec.gmk [v2]
In-Reply-To: <2Q5PpwofvoFbtGGmvpwZO0GRpdsinjyFjx7Rcxavs68=.34f643f4-7c13-45c5-bf7e-7753585d7056@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
 <7dMRpo7dGGmy9-eTPPbP5UKvW7cBy8e_A0yYzlfVER0=.2071c4cd-7a7b-493d-990f-d7c41aadb803@github.com>
 <2Q5PpwofvoFbtGGmvpwZO0GRpdsinjyFjx7Rcxavs68=.34f643f4-7c13-45c5-bf7e-7753585d7056@github.com>
Message-ID: <E7jZh6k9L-So_ZeVyoAT7KFI9UJGQ2EcsGHiAIuOrdQ=.419a9d51-214f-4632-a8a1-2b73be55c95b@github.com>

On Wed, 24 Sep 2025 14:54:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/common/CommonVars.gmk line 222:
>> 
>>> 220: 
>>> 221: # You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java $(NEW_JAVAC) ...
>>> 222: # Use = assignment to be able to override in bootcycle-spec.gmk
>> 
>> This comment isn't correct anymore.
>
> There were many issues here. First of all, NEW_JAVAC is not used anymore so it is dead code. Secondly, we still need = assignment for bootcycle builds, but only for JAVADOC. But this is not technically done in bootcycle-spec.gmk anymore. 
> 
> I removed the dead code and updated the comment, hope you are okay with it.
> 
> There's a lot of cleaning work needed for this file. At this point, I just wanted to do a clear a separation as possible.

I understand that there is a lot of cleanup needed. I only pointed this out as it was a comment that was obviously becoming outdated by this change and similar comments in other places had different wordings that still worked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27452#discussion_r2376686297

From tanksherman27 at gmail.com  Wed Sep 24 18:52:00 2025
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 25 Sep 2025 02:52:00 +0800
Subject: Problems with LTO for HotSpot
Message-ID: <CAP2b4GPhcm_sjmAzm4DVmFXb8+kn3hr4v5QS_f_dV3kzKmNQ8A@mail.gmail.com>

>From what I know, the flatten attribute pretty much tells gcc "Forget
heuristics, inline everything into this method" and is basically you
telling the compiler that you know better than it in this case. It
(And always_inline) wouldn't be very useful if they didn't do what you
requested of the compiler based on its mood. But the bigger problem
according to some chats with the gcc developers is that the flatten
attribute simply just wasn't made with LTO in mind and so doesn't
check if a method is defined in another source file before inlining
it. Short of something like adding a parameter to the flatten
attribute to disable cross compilation unit inlining within gcc itself
(Or something along those lines), there's nothing much one can do
aside from use noinline as appropriate to stop the inlining madness
from happening, unfortunately.

best regards,
Julian

From kim.barrett at oracle.com  Wed Sep 24 22:16:27 2025
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 24 Sep 2025 18:16:27 -0400
Subject: Problems with LTO for HotSpot
In-Reply-To: <CAP2b4GMgjvJZt1a_tqZR2UNLkqZ-OZORgTOdeAoyW9n2aowg1g@mail.gmail.com>
References: <CAP2b4GMgjvJZt1a_tqZR2UNLkqZ-OZORgTOdeAoyW9n2aowg1g@mail.gmail.com>
Message-ID: <736d1d36-bb0e-4661-987c-12bf05bebe54@oracle.com>

On 9/24/25 1:08 PM, Julian Waters wrote:
> Recently I've been picking up and resuming work on making LTO viable
> for HotSpot. [...] The bigger issue is related to the flatten attribute
> on the gcc compiler. In short, some G1 code (More specifically void
> G1ParScanThreadState::trim_queue_to_threshold(uint threshold), void
> G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet*
> task_queues) and oop
> G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr
> region_attr, oop old, markWord old_mark)) is marked as flatten

The flatten attribute is being used there because the code in question has
been found to be very (performance) sensitive to compiler decisions to
sometimes not inline something. So apply the big hammer.

(Note that some critical path stuff is conditionally noinline in debug builds,
because otherwise such builds were also running into excessive inlining,
leading to things like "conditional branch out of range" failures.)

Using flatten is certainly leading to more inlining than actually needed.

An alternative to using flatten would be to try to mark all the critical path
stuff always_inline. I found that pretty hard to do, and also brittle, much
like Julian is encountering with the flatten + noinline approach.

But it might be that some judicious always_inline + noinline + either (but not
both) flatten or LTO might work. That was the direction I was going to
explore, but haven't found any spare 'tuits to allocate in that direction.
Supporting LTO just hasn't percolated up the priority list here.


From dholmes at openjdk.org  Thu Sep 25 03:19:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 03:19:47 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt
In-Reply-To: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
Message-ID: <8GrwvSQl9pwO37Iq0ooZ4VUo5KWxij7Mfz8wX-5K8U0=.3d667644-00da-4341-a2fe-e6bca4962cd8@github.com>

On Wed, 24 Sep 2025 15:30:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
> 
> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.

Changes requested by dholmes (Reviewer).

make/autoconf/libraries.m4 line 141:

> 139:   # librt
> 140:   if test "x$OPENJDK_TARGET_OS" = xlinux; then
> 141:     # Needed for the timer_* functions from librt used in JFR

It isn't just JFR - CompilerThreadTimeout also uses timers. I suggest just one comment at line 139 "#librt - for timers".

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

PR Review: https://git.openjdk.org/jdk/pull/27473#pullrequestreview-3265452716
PR Review Comment: https://git.openjdk.org/jdk/pull/27473#discussion_r2377578541

From jkern at openjdk.org  Thu Sep 25 07:40:03 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 25 Sep 2025 07:40:03 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
Message-ID: <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>

> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  indentation and typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27468/files
  - new: https://git.openjdk.org/jdk/pull/27468/files/a459f293..e3f3a995

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

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

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

From mbaesken at openjdk.org  Thu Sep 25 07:44:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Sep 2025 07:44:50 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt
In-Reply-To: <8GrwvSQl9pwO37Iq0ooZ4VUo5KWxij7Mfz8wX-5K8U0=.3d667644-00da-4341-a2fe-e6bca4962cd8@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
 <8GrwvSQl9pwO37Iq0ooZ4VUo5KWxij7Mfz8wX-5K8U0=.3d667644-00da-4341-a2fe-e6bca4962cd8@github.com>
Message-ID: <DsqYuWwm7RfgsoifugHFPD5hPp9Hunsw4l5JRaS1yU0=.416f3e90-eb72-4535-94e9-3a569f2cb9b1@github.com>

On Thu, 25 Sep 2025 03:16:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
>> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
>> 
>> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
>> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.
>
> make/autoconf/libraries.m4 line 141:
> 
>> 139:   # librt
>> 140:   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>> 141:     # Needed for the timer_* functions from librt used in JFR
> 
> It isn't just JFR - CompilerThreadTimeout also uses timers. I suggest just one comment at line 139 "#librt - for timers".

Additional to JFR I see some stuff in ASSERT coding in the compiler threads coding using  `timer_*` so it is not important for release JVMs.  But probably you are right we can simplify the comments, no need to mention old stuff and too many details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27473#discussion_r2378062934

From mbaesken at openjdk.org  Thu Sep 25 08:05:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Sep 2025 08:05:23 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt [v2]
In-Reply-To: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
Message-ID: <_EvznsMOK4Lzf7yU-kSgcVsSsqyW4DMmTmd-5EEZutQ=.ac8da4b2-a3e8-42d3-98d5-d017d215aa7c@github.com>

> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
> 
> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.

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

  adjust/simplify comment regarding librt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27473/files
  - new: https://git.openjdk.org/jdk/pull/27473/files/980de745..745bf7f4

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

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

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

From mhaessig at openjdk.org  Thu Sep 25 08:13:12 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 25 Sep 2025 08:13:12 GMT
Subject: RFR: 8368615: VSCode IDE: Oracle Java extension routinely runs out of
 memory
Message-ID: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>

This PR increases the maximum heap size for language server of the Oracle Java VSCode extension from 1GB to 2GB. Without this increase, the server runs out of memory when scanning the large code base of the JDK and starts hogging the CPU.

I have been using this configuration for the past few days and it is working well.

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

Commit messages:
 - Increase language server heap size

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

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

From mbaesken at openjdk.org  Thu Sep 25 09:17:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Sep 2025 09:17:46 GMT
Subject: RFR: 8357691: File blocked.certs contains bad content when boot jdk 25
 is used, sun/security/lib/CheckBlockedCerts.java failing
Message-ID: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>

When using boot JDK 25 we end up with bad content in  lib/security/blocked.certs  because  cds related warning output shows up there.

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

Commit messages:
 - JDK-8357691

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

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

From prappo at openjdk.org  Thu Sep 25 09:28:21 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 Sep 2025 09:28:21 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <tVl44y_rz9r_0Va-njcyXluLoI9jROTlQBPulObu618=.602b9271-5d51-43fe-89d5-3b4a307f57a2@github.com>
 <8zSBYHWXazhdwlpRxMJW0k5gYZDEshXtKo2ToQxoHiw=.c6c7e5c9-4ad3-4435-b7b2-6bfb0a9371e7@github.com>
 <xp8xgupDhAtMqw15pU2btl5J7t8UZGBHogPWZuenwfc=.0f898747-c435-4e1d-ad10-764949858ed0@github.com>
 <-8TLt8uqvhTgk9TrvHb-L0Rf4nalm3u1sP8UkFrC-Wg=.fdbd7008-4346-4a5d-9dae-1fb7887cc7a0@github.com>
 <Y2ojwPOmqhHXDufIsIu2p-X6bH09YBvofwKi4FPjYwg=.4ec25a44-0309-4322-9806-dc312631904f@github.com>
 <Z_G-6g2qIb8tJa-yypvgg0MakwXwDJ3ceH5-FsNd1mI=.ef826df3-04f3-4ab3-93d5-fcb0a6b14479@github.com>
 <sgelyMB-_LFjIC_qJliK7KkQJHppSN4xmI31lVD325Q=.900df29e-7114-4fa1-b879-6a06225d1f01@github.com>
 <_QblLaoRLKcV6Mf8E3WFd-zpuxn3OKOUHfW0Gez7_0I=.d69c5927-075c-4008-8f62-f447816925f6@github.com>
Message-ID: <yK3-T1rhgm6HBuNTsDCEaRIpw-LeeAA5gFjFUiF4stI=.e5072fc7-8cfc-47b4-8ea2-9716464bddd1@github.com>

On Wed, 24 Sep 2025 16:45:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I can think of one possible wrinkle though: warnings can actually be suppressed in the source code in two ways, by `@SuppressWarnings` and by `@Deprecated` (see `Lint.suppressionsFrom(Symbol)`). So you'd also have to look for `@Deprecated`; but this also brings up the unsettling possibility that in the future, some new annotation might have a similar side-effect, and then we'd be in trouble again. So there is an aspect of this idea that requires us to make certain predictions about the future, which of course is dangerous. I think it's safer to "just say no".

`@Deprecated` as well as a conceivable future tag whose secondary effect is to silence possible warnings are very different from `@SuppressWarnings`. While I don't see why we might need to consider those underneath `@SuppressWarnings("suppression")` to decide if it should emit a warning, it's okay to say that it's safer not to complicate things. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3333072769

From duke at openjdk.org  Thu Sep 25 12:44:33 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 12:44:33 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <LbtKjOFGsHTibAzEPUiW9ZqBktChIHNCRguabF9NWAA=.d17d091e-79d8-40eb-b320-cd36aac1503c@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'openjdk:master' into jdk-8360498
 - Removes not needed changes
 - Revert "Removes not needed changes"
   
   This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
 - Removes not needed changes
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14
  Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Thu Sep 25 13:03:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 13:03:51 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Resolves confict for when there is a merge with jdk-8158801

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15

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

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

From erikj at openjdk.org  Thu Sep 25 13:07:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 25 Sep 2025 13:07:51 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
Message-ID: <ZzAdRj_wx6pORZSLZdVbcdTMNdSG_rmeZnet88ykHiY=.d8ff76fb-2473-4ea6-9504-78417624d891@github.com>

On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
>> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
>> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation and typo

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3267557349

From erikj at openjdk.org  Thu Sep 25 13:08:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 25 Sep 2025 13:08:54 GMT
Subject: RFR: 8368615: VSCode IDE: Oracle Java extension routinely runs out
 of memory
In-Reply-To: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>
References: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>
Message-ID: <k9ktEkWvBsKNOL7j4RGGIO4ChdhzX3AtOnEZOEMMTkI=.e028e6d1-6ed6-49cb-93ee-c2c68214a1f5@github.com>

On Thu, 25 Sep 2025 08:06:12 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR increases the maximum heap size for language server of the Oracle Java VSCode extension from 1GB to 2GB. Without this increase, the server runs out of memory when scanning the large code base of the JDK and starts hogging the CPU.
> 
> I have been using this configuration for the past few days and it is working well.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27483#pullrequestreview-3267564933

From erikj at openjdk.org  Thu Sep 25 13:10:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 25 Sep 2025 13:10:56 GMT
Subject: RFR: 8357691: File blocked.certs contains bad content when boot
 jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing
In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
Message-ID: <I0KX-jmpvbVL0q31PVKW0M7UnSaIKNs9gXTaC2gJ_zo=.3fd5ad71-e063-4e83-a0c2-a408a32158f5@github.com>

On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using boot JDK 25 we end up with bad content in  lib/security/blocked.certs  because  cds related warning output shows up there.
> 
> The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this
> 
> 
>> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
>> [0.010s][error][cds] Disabling optimized module handling

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27485#pullrequestreview-3267576234

From alanb at openjdk.org  Thu Sep 25 13:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Sep 2025 13:30:34 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
Message-ID: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>

On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolves confict for when there is a merge with jdk-8158801

What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893

From mbaesken at openjdk.org  Thu Sep 25 13:50:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Sep 2025 13:50:35 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
Message-ID: <GKYL_-6b-OQkyhobL919xStThQRgwDhgejZKpMvLhmI=.7732561c-f8c1-4abe-9dcf-cbc4ad04a5f4@github.com>

On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
>> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
>> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation and typo

Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s`  into the AIX link flags, is that observation correct?
So the change does not only touch ubsan but all linkage on this platform ?
What are the pros and cons ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3334193844

From duke at openjdk.org  Thu Sep 25 14:00:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:08 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <IFBetIfNildsjk1H900soCAiLg2EM8nsjrkfKOPWBV4=.4ccfcb8f-ec0e-4c6b-a713-c604c6a9f114@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8360498
 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling
   
   Reviewed-by: aph, rcastanedalo
 - 8367103: RISC-V: store cpu features in a bitmap
   
   Reviewed-by: fyang, luhenry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16

  Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Thu Sep 25 14:00:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 25 Sep 2025 14:00:10 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16]
In-Reply-To: <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com>
 <qCdRyzzEZkz-BhwZbGHWty81mOSB7ae9pu9B7FmSKSs=.f77f53d2-5df1-4829-83d7-a4aefaae732b@github.com>
Message-ID: <URXFmVJhmSe8PBZ4Vdbqw_lKQyw9TfofauV5j6QYwzA=.50d49205-a08a-4147-a97e-66f090371efc@github.com>

On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Resolves confict for when there is a merge with jdk-8158801
>
> What is this about? The PR suggests 500+ commits and 300+  files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists.

@AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324

From stuefe at openjdk.org  Thu Sep 25 14:45:19 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Sep 2025 14:45:19 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
Message-ID: <bYeONMkgEnouBd_LRr06y64KihXSzv2tZNJrtsIAG58=.77b42709-e21e-476a-b9d1-3bbd5920c4fe@github.com>

On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
>> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
>> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation and typo

Good!

Ah, I missed @MBaesken s remark. Up to you, but I would do this only for ubsan.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3268141835

From ihse at openjdk.org  Thu Sep 25 15:27:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 25 Sep 2025 15:27:05 GMT
Subject: RFR: 8368674: Incremental builds keep rebuilding interim jmod
Message-ID: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>

After [JDK-8366899](https://bugs.openjdk.org/browse/JDK-8366899), the interim jmods will be constantly rebuilt during incremental builds, triggering a cascade that ends with the entire JDK image being rebuilt.

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

Commit messages:
 - 8368674: Incremental builds keep rebuilding interim jmod

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

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

From cstein at openjdk.org  Thu Sep 25 15:27:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 Sep 2025 15:27:06 GMT
Subject: RFR: 8368674: Incremental builds keep rebuilding interim jmod
In-Reply-To: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
References: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
Message-ID: <wnqpdhrcZogmgxKEO6fnH3cjfNaiWNsZeCZ9o5aIsRU=.21cbfcc8-799f-403c-8d10-8bed7d724c57@github.com>

On Thu, 25 Sep 2025 13:51:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8366899](https://bugs.openjdk.org/browse/JDK-8366899), the interim jmods will be constantly rebuilt during incremental builds, triggering a cascade that ends with the entire JDK image being rebuilt.

Looks good to me; a local test without changes showed no more rebuilds.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27490#pullrequestreview-3268066466

From jkern at openjdk.org  Thu Sep 25 15:45:31 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 25 Sep 2025 15:45:31 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <GKYL_-6b-OQkyhobL919xStThQRgwDhgejZKpMvLhmI=.7732561c-f8c1-4abe-9dcf-cbc4ad04a5f4@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
 <GKYL_-6b-OQkyhobL919xStThQRgwDhgejZKpMvLhmI=.7732561c-f8c1-4abe-9dcf-cbc4ad04a5f4@github.com>
Message-ID: <Nl1YM_607kKoXPO1Z4RN75vBnV9vy1kkSG_CScDzPFk=.9e82fda3-532e-44df-aa25-af73fda318a8@github.com>

On Thu, 25 Sep 2025 13:48:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ?

I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler.

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

PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3334805925

From erikj at openjdk.org  Thu Sep 25 16:45:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 25 Sep 2025 16:45:01 GMT
Subject: RFR: 8368674: Incremental builds keep rebuilding interim jmod
In-Reply-To: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
References: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
Message-ID: <m8u2Ns3MsXTbMSuiSQrn6v2sTvJGdi9atl6Mo1lRvjs=.ccfb0cf5-b5f4-4266-9317-1683b2b89151@github.com>

On Thu, 25 Sep 2025 13:51:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8366899](https://bugs.openjdk.org/browse/JDK-8366899), the interim jmods will be constantly rebuilt during incremental builds, triggering a cascade that ends with the entire JDK image being rebuilt.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27490#pullrequestreview-3268648851

From ihse at openjdk.org  Thu Sep 25 17:46:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 25 Sep 2025 17:46:11 GMT
Subject: Integrated: 8368468: Split out everything but configure results from
 spec.gmk
In-Reply-To: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
References: <Qv2YyOkJnMZv1pp9_Ne66hhLNELRSFrt8QduAtkmS9A=.8e7f9a2d-7615-43b4-9d31-5954adb2df04@github.com>
Message-ID: <UTnWPSkkgGkI62zZwa3gjBP7FnCDuSlMPJHGBwXo9Fs=.097f6b87-8ef0-446b-a370-59a6646149fd@github.com>

On Tue, 23 Sep 2025 13:48:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Most of spec.gmk contains lines on the form:
> 
> VAR := @VAR@
> 
> which are setup using `AC_SUBST(VAR)` in the configure script. However, there are also some other stuff there, which are mostly put there since we had no other good place to do so.
> 
> I have now created a new file, `CommonVars.gmk`, which is automatically included, and moved everything but pure configure assignments from `spec.gmk` into this file.
> 
> That makes `spec.gmk` a great interface between configure and make -- the job of configure is to fill in `spec.gmk`, plain and simple.
> 
> This refactoring also points to additional future improvements, e.g. generating `spec.gmk` automatically from all `AC_SUBST` statements, and to clean up the new `CommonVars.gmk`. Right now I kept all lines in the same order as they appeared in `spec.gmk.template`, to minimize risk of unintentional changes (we have some non-`:=` assignments), and to facilitate comparison for this patch. It is also clear that we have room for improvement in how we do bootcycle-builds and build the build-jdk. My current solution is to keep the special spec files, even if they just set a single special flag, to minimize impact of this patch.

This pull request has now been integrated.

Changeset: de1f5a3c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53
Stats:     938 lines in 12 files changed: 472 ins; 413 del; 53 mod

8368468: Split out everything but configure results from spec.gmk

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Thu Sep 25 17:48:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 25 Sep 2025 17:48:14 GMT
Subject: Integrated: 8368674: Incremental builds keep rebuilding interim jmod
In-Reply-To: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
References: <4d9doE5vpr7xe1ZxE5fNu14NwQyN0ZqCRAImAcZ2t9Q=.9252ce96-e543-47b7-bf06-2f42730000c7@github.com>
Message-ID: <DkoREmq-OVv15zBzXS2Fzz2Xv3m-hKSsdw4YZJxYXQM=.7bfbe203-2786-478b-96e2-68d697c2a263@github.com>

On Thu, 25 Sep 2025 13:51:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8366899](https://bugs.openjdk.org/browse/JDK-8366899), the interim jmods will be constantly rebuilt during incremental builds, triggering a cascade that ends with the entire JDK image being rebuilt.

This pull request has now been integrated.

Changeset: 32ab0dbc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32ab0dbc0b8170ecd168dbb7c3f1be69dfa5299b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368674: Incremental builds keep rebuilding interim jmod

Reviewed-by: cstein, erikj

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

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

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 dholmes at openjdk.org  Thu Sep 25 21:21:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 Sep 2025 21:21:04 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt [v2]
In-Reply-To: <_EvznsMOK4Lzf7yU-kSgcVsSsqyW4DMmTmd-5EEZutQ=.ac8da4b2-a3e8-42d3-98d5-d017d215aa7c@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
 <_EvznsMOK4Lzf7yU-kSgcVsSsqyW4DMmTmd-5EEZutQ=.ac8da4b2-a3e8-42d3-98d5-d017d215aa7c@github.com>
Message-ID: <xCDMynRG5djqpnaOmPdnVpV3LpnXfMp9DW_4mC7xDVE=.547c0a0f-4b4f-4e41-b667-b346761324d1@github.com>

On Thu, 25 Sep 2025 08:05:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
>> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
>> 
>> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
>> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust/simplify comment regarding librt

Looks good and trivial.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27473#pullrequestreview-3269497029

From iklam at openjdk.org  Fri Sep 26 00:53:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 26 Sep 2025 00:53:16 GMT
Subject: RFR: 8357691: File blocked.certs contains bad content when boot
 jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing
In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
Message-ID: <lp7wF8KLDpze1lq5br7_TkqkbL2qky2Q6vZlL7Wo4us=.5290c754-ba09-4f98-bc82-3843184a9cba@github.com>

On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using boot JDK 25 we end up with bad content in  lib/security/blocked.certs  because  cds related warning output shows up there.
> 
> The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this
> 
> 
>> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
>> [0.010s][error][cds] Disabling optimized module handling

Marked as reviewed by iklam (Reviewer).

The fix looks OK to me.

Background: when using the default CDS archive, such warnings are disabled. The reason is -- we assume the default archive is general purpose and can be used for different sets of command-lines. We don't print warnings as it's not "wrong" for the app to specify ` --add-exports`.


$ ${JAVA_HOME}/bin/java --add-exports=java.base/sun.security.util=ALL-UNNAMED --version
java 26-internal 2026-03-17
Java(TM) SE Runtime Environment (build 26-internal-adhoc.iklam.rum)
JavaHotSpot(TM) 64-Bit Server VM (build 26-internal-adhoc.iklam.rum, mixed mode, sharing)


But when you are using `-XX:SharedArchiveFile` to specify a CDS archive, we assume that the archive has been tailored to the specific application that you're using, so the warnings are printed more eagerly, as you might have unintentionally given an incompatible VM option: 


$ cp ${JAVA_HOME}/lib/server/classes.jsa foo.jsa
$ ${JAVA_HOME}/bin/java -XX:SharedArchiveFile=foo.jsa --add-exports=java.base/sun.security.util=ALL-UNNAMED --version
[0.026s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
[0.026s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
[0.026s][error][cds] Disabling optimized module handling
java 26-internal 2026-03-17
Java(TM) SE Runtime Environment (build 26-internal-adhoc.iklam.rum)
JavaHotSpot(TM) 64-Bit Server VM (build 26-internal-adhoc.iklam.rum, mixed mode, sharing)


In this case, I think the JDK build system creates its own CDS archive with the BOOT JDK, so it falls under the second scenario. Using `-Xlog:cds=off` is appropriate.

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

PR Review: https://git.openjdk.org/jdk/pull/27485#pullrequestreview-3269822895
PR Comment: https://git.openjdk.org/jdk/pull/27485#issuecomment-3336409510

From mbaesken at openjdk.org  Fri Sep 26 07:14:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 07:14:17 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <Nl1YM_607kKoXPO1Z4RN75vBnV9vy1kkSG_CScDzPFk=.9e82fda3-532e-44df-aa25-af73fda318a8@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
 <GKYL_-6b-OQkyhobL919xStThQRgwDhgejZKpMvLhmI=.7732561c-f8c1-4abe-9dcf-cbc4ad04a5f4@github.com>
 <Nl1YM_607kKoXPO1Z4RN75vBnV9vy1kkSG_CScDzPFk=.9e82fda3-532e-44df-aa25-af73fda318a8@github.com>
Message-ID: <qq0W4ne4AvNQXJsEQM4x5kvyVpXnijdE7CTD6hBVV0o=.eb89fe49-fee4-4931-a90e-386115602281@github.com>

On Thu, 25 Sep 2025 15:42:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> > Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ?
> 
> I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler.

So what does the added flag (especially in the 'normal' non-sanitizer enabled builds) and what's the benefit we get from it (so far we lived happily without it).

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

PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3337085584

From mbaesken at openjdk.org  Fri Sep 26 07:59:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 07:59:51 GMT
Subject: RFR: 8357691: File blocked.certs contains bad content when boot
 jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing
In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
Message-ID: <YGxJAgUswvMHvzjFVxlSF3ol5P1Ft1gbwjZIa7-S44s=.db029f7a-8c0b-4efc-b1b5-d4b22b5fe365@github.com>

On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using boot JDK 25 we end up with bad content in  lib/security/blocked.certs  because  cds related warning output shows up there.
> 
> The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this
> 
> 
>> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
>> [0.010s][error][cds] Disabling optimized module handling

Hi Ioi , thanks for the detailed explanation, why this happens.

And thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/27485#issuecomment-3337221857

From mbaesken at openjdk.org  Fri Sep 26 07:59:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 07:59:52 GMT
Subject: Integrated: 8357691: File blocked.certs contains bad content when boot
 jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing
In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com>
Message-ID: <_eurWb9v-Pzr0kciLOuvhvWhoYiwvYbtYEpv6I9Dd4Y=.6b4f8de5-f277-4597-855d-9d4d9172cfdd@github.com>

On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using boot JDK 25 we end up with bad content in  lib/security/blocked.certs  because  cds related warning output shows up there.
> 
> The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this
> 
> 
>> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
>> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time
>> [0.010s][error][cds] Disabling optimized module handling

This pull request has now been integrated.

Changeset: a80ba626
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a80ba6260effdca7a7703c6903f273401b861793
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing

Reviewed-by: erikj, iklam

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

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

From mbaesken at openjdk.org  Fri Sep 26 09:03:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 09:03:44 GMT
Subject: Integrated: 8368565: Adjust comment regarding dependency of libjvm.so
 to librt
In-Reply-To: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
Message-ID: <i_Q6Ct_ZX8SoUMKBFsPgoEB9AYHYnAcPJkn-CDRTmgg=.242445d8-ef60-419e-a8e5-a5fee348794c@github.com>

On Wed, 24 Sep 2025 15:30:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
> 
> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.

This pull request has now been integrated.

Changeset: 7bfdb012
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7bfdb0120752d01da96c19e8037a6e909847d63c
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8368565: Adjust comment regarding dependency of libjvm.so to librt

Reviewed-by: dholmes

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

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

From mbaesken at openjdk.org  Fri Sep 26 09:03:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 09:03:43 GMT
Subject: RFR: 8368565: Adjust comment regarding dependency of libjvm.so to
 librt [v2]
In-Reply-To: <_EvznsMOK4Lzf7yU-kSgcVsSsqyW4DMmTmd-5EEZutQ=.ac8da4b2-a3e8-42d3-98d5-d017d215aa7c@github.com>
References: <uvkrA50YwE8-esLC4FwsiJFXkFOcGMiEACNVHYYYuKQ=.e8586180-72a9-4df5-8ef0-86bcccb0fbcc@github.com>
 <_EvznsMOK4Lzf7yU-kSgcVsSsqyW4DMmTmd-5EEZutQ=.ac8da4b2-a3e8-42d3-98d5-d017d215aa7c@github.com>
Message-ID: <WOtKWSI_DOEcdAAc88vymX94yMAx-htILT5aKMae950=.69762117-d9cc-4bfc-9460-4121bb4f2f21@github.com>

On Thu, 25 Sep 2025 08:05:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have a legacy dependency of libjvm to librt for the` clock_*` functions :
>> https://github.com/openjdk/jdk/blob/f993f90c86f89eb0c7f42ebecb45a68eae0bd9ea/make/autoconf/libraries.m4#L139
>> 
>> But this is for very old systems with distros like RHEL 6 or SLES11 with glibc 2.16 or older, where the clock_ functions were still in librt ; but those ancient distros play no role any more for current JDK26.
>> On the other hand, we now use the `timer_*` functions from librt e.g. in JFR and these are _really_  in librt so the comment should be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust/simplify comment regarding librt

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/27473#issuecomment-3337467607

From jkern at openjdk.org  Fri Sep 26 12:01:46 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 26 Sep 2025 12:01:46 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <qq0W4ne4AvNQXJsEQM4x5kvyVpXnijdE7CTD6hBVV0o=.eb89fe49-fee4-4931-a90e-386115602281@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
 <GKYL_-6b-OQkyhobL919xStThQRgwDhgejZKpMvLhmI=.7732561c-f8c1-4abe-9dcf-cbc4ad04a5f4@github.com>
 <Nl1YM_607kKoXPO1Z4RN75vBnV9vy1kkSG_CScDzPFk=.9e82fda3-532e-44df-aa25-af73fda318a8@github.com>
 <qq0W4ne4AvNQXJsEQM4x5kvyVpXnijdE7CTD6hBVV0o=.eb89fe49-fee4-4931-a90e-386115602281@github.com>
Message-ID: <oX4cRif_Ulg35WuO3I-WkkSj1udZazuese9wKrU116U=.4771d930-6078-4256-aec1-56a6585eea26@github.com>

On Fri, 26 Sep 2025 07:11:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > > Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ?
> > 
> > 
> > I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler.
> 
> So what does the added flag (especially in the 'normal' non-sanitizer enabled builds) and what's the benefit we get from it (so far we lived happily without it).

This linker flag maintains the well-established order of initialization of static constructors, as known from the former xlC.

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

PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3338331863

From mbaesken at openjdk.org  Fri Sep 26 12:06:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Sep 2025 12:06:49 GMT
Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow
 up of JDK-8354686) [v2]
In-Reply-To: <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
 <iigcfHAJVDLf-YTvc1zGxtdurFojofBcB20oXZKlto8=.04c0eede-1fda-45e8-87bc-2abdad7dce9c@github.com>
Message-ID: <Gi5UAJmOnt8S14ObZ5IuEuUs00efme_nYlyuVZVUrnk=.10448fcf-a2ec-4486-a2ea-8771523d2d3e@github.com>

On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
>> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
>> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation and typo

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3271944238

From jkern at openjdk.org  Fri Sep 26 12:18:28 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 26 Sep 2025 12:18:28 GMT
Subject: Integrated: 8368250: [AIX] now ubsan vptr check is also possible
 (follow up of JDK-8354686)
In-Reply-To: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
References: <LdLC91oOtBgUvJeR-BkWzx25SDQtyyPaRTo7d2JocBA=.be9ad91c-30ca-4af2-b4d2-606c99b58bf4@github.com>
Message-ID: <G6p9UlNRqpQRQS-cLeAw_-3q9D9Yy5-ZmfEq8mYmvaI=.1a46a2e3-e1ac-41b1-9818-60db9dda5fb5@github.com>

On Wed, 24 Sep 2025 13:23:00 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend.
> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend.
> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode.

This pull request has now been integrated.

Changeset: f0e1078c
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0e1078c7175b3f930502a6079feff86aa53b669
Stats:     9 lines in 3 files changed: 5 ins; 0 del; 4 mod

8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686)

Reviewed-by: erikj, stuefe, mbaesken

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

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

From mhaessig at openjdk.org  Fri Sep 26 14:31:50 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 14:31:50 GMT
Subject: RFR: 8368615: VSCode IDE: Oracle Java extension routinely runs out
 of memory
In-Reply-To: <k9ktEkWvBsKNOL7j4RGGIO4ChdhzX3AtOnEZOEMMTkI=.e028e6d1-6ed6-49cb-93ee-c2c68214a1f5@github.com>
References: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>
 <k9ktEkWvBsKNOL7j4RGGIO4ChdhzX3AtOnEZOEMMTkI=.e028e6d1-6ed6-49cb-93ee-c2c68214a1f5@github.com>
Message-ID: <mcgbUFPSYyTjWnKl7gT8DXe_L-brFLC9homcmqsrs9I=.f48d4d20-f31f-4cf0-b531-c49ec555fc73@github.com>

On Thu, 25 Sep 2025 13:06:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR increases the maximum heap size for language server of the Oracle Java VSCode extension from 1GB to 2GB. Without this increase, the server runs out of memory when scanning the large code base of the JDK and starts hogging the CPU.
>> 
>> I have been using this configuration for the past few days and it is working well.
>
> Marked as reviewed by erikj (Reviewer).

Thank you for your review, @erikj79.

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

PR Comment: https://git.openjdk.org/jdk/pull/27483#issuecomment-3338967963

From mhaessig at openjdk.org  Fri Sep 26 14:31:51 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 14:31:51 GMT
Subject: Integrated: 8368615: VSCode IDE: Oracle Java extension routinely runs
 out of memory
In-Reply-To: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>
References: <ra2Wx-PHHhGlM46oAV3sK16_ZFbklsNmuZioFbpxJec=.40c03ca0-7a22-43f0-a1c9-9496885a6b50@github.com>
Message-ID: <kkWbRCxuHxYX5XG0yGDlvyXrJnf7F2CTEAaap7QICeQ=.bffb8d1a-ac0a-453e-bcb6-579a7957f7e4@github.com>

On Thu, 25 Sep 2025 08:06:12 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR increases the maximum heap size for language server of the Oracle Java VSCode extension from 1GB to 2GB. Without this increase, the server runs out of memory when scanning the large code base of the JDK and starts hogging the CPU.
> 
> I have been using this configuration for the past few days and it is working well.

This pull request has now been integrated.

Changeset: 501b2b3e
Author:    Manuel H?ssig <mhaessig at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/501b2b3ebc50d9bb1c32267ef8e56561ea1e71eb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8368615: VSCode IDE: Oracle Java extension routinely runs out of memory

Reviewed-by: erikj

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

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

From acobbs at openjdk.org  Sun Sep 28 18:56:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 28 Sep 2025 18:56:01 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v2]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <5Yc8i9GJZU7D_rezsZX5g6ud_5AIs0sNeFf3pf-fA-E=.0585ea54-97f0-4a54-831f-3239ae1386ae@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 131 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - Minor regression test cleanups.
 - ... and 121 more: https://git.openjdk.org/jdk/compare/9093d3a0...7714095d

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=01
  Stats: 1658 lines in 33 files changed: 1485 ins; 49 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From myankelevich at openjdk.org  Mon Sep 29 10:28:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 29 Sep 2025 10:28:19 GMT
Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3]
In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
Message-ID: <iWr9NfPTK1SgsC0M8bFlnv0tRvIeCPI4P_X9J_ddrHo=.685f585d-dcad-4c49-b3e8-5884faeeb05f@github.com>

> Tests changed in this PR: 
> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
> 12. test/jdk/sun/security/rsa/InvalidBitString.java
> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
> 
> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)

Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision:

 - removed pemrecord usage
 - 8365190: Remove LockingMode related code from share
   
   Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo
 - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp
   
   Reviewed-by: aboldtch, tschatzl, jwaters
 - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement
   
   Reviewed-by: dlong, mdoerr
 - 8366864: Sort os/linux includes
   
   Reviewed-by: ayang, dholmes
 - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages
   
   Reviewed-by: ayang, shade, stefank, tschatzl
 - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR)
   
   Reviewed-by: vromero
 - 8365776: Convert JShell tests to use JUnit instead of TestNG
   
   Reviewed-by: vromero
 - 8354871: Replace stack map frame type magics with constants
   
   Reviewed-by: liach
 - 8361533: Apply java.io.Serial annotations in java.logging
   
   Reviewed-by: rriggs
 - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27194/files
  - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa

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

  Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod
  Patch: https://git.openjdk.org/jdk/pull/27194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194

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

From erikj at openjdk.org  Tue Sep 30 13:08:47 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 30 Sep 2025 13:08:47 GMT
Subject: RFR: 8367026: Reorder the timeout failure handler commands to have
 jstack run before the rest
In-Reply-To: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
References: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
Message-ID: <dkVui252NE6DpAtmQPQ3FNjlgUEcV1-vd3Ks_DceRv4=.068e3f82-2990-4327-8eed-07e966428b6f@github.com>

On Tue, 30 Sep 2025 11:37:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to a jtreg failure handler configured in the JDK?
> 
> The change proposes to generate a thread dump much sooner than previously whenever a test times out. This should thus capture a much more accurate state of the test process when the test is considered timed out.
> 
> Due to the recent changes in the default timeout factor, we have noticed some tests which timeout and the jtreg failure handler actions start execution. While those are being executed the test sometimes completes. So by the time the "jstack" failure handler action is executed (can be several seconds later), the test's state will no longer be accurate.
> 
> The change here generates a thread dump using jstack as the first action in the set of failure handler actions. It does it only once and then moves to the rest of the actions, one of which subsequent "jstack" which generates thread dumps more than once.
> 
> I have verified that this change works as expected when a test times out. The action is named "thread_dump" instead of just reusing the "jstack" name because the current HTML rendering of the processes.html runs into trouble if there are more than one action with the same name.
> 
> I wanted to reorder some of the other commands in that set, but it causes some trouble in the rendering of the HTML and would require some changes to that part. So I decided to keep this simple and have it done sooner to help investigating timeout failures in our CI.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27574#pullrequestreview-3284673134

From lmesnik at openjdk.org  Tue Sep 30 14:47:05 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Sep 2025 14:47:05 GMT
Subject: RFR: 8367026: Reorder the timeout failure handler commands to have
 jstack run before the rest
In-Reply-To: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
References: <MI6hWYYYACr-gEUwxXQg04YvFbVbanAyvlY18AkaLyI=.43bdb669-8615-4bf4-8232-cb4c6165f10e@github.com>
Message-ID: <qcWdLvrvaPmHTpKcDzQCNjsVLVHsEE8w_ePC2xQUanE=.60e131c6-54e4-407f-95ec-a949ea71e063@github.com>

On Tue, 30 Sep 2025 11:37:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to a jtreg failure handler configured in the JDK?
> 
> The change proposes to generate a thread dump much sooner than previously whenever a test times out. This should thus capture a much more accurate state of the test process when the test is considered timed out.
> 
> Due to the recent changes in the default timeout factor, we have noticed some tests which timeout and the jtreg failure handler actions start execution. While those are being executed the test sometimes completes. So by the time the "jstack" failure handler action is executed (can be several seconds later), the test's state will no longer be accurate.
> 
> The change here generates a thread dump using jstack as the first action in the set of failure handler actions. It does it only once and then moves to the rest of the actions, one of which subsequent "jstack" which generates thread dumps more than once.
> 
> I have verified that this change works as expected when a test times out. The action is named "thread_dump" instead of just reusing the "jstack" name because the current HTML rendering of the processes.html runs into trouble if there are more than one action with the same name.
> 
> I wanted to reorder some of the other commands in that set, but it causes some trouble in the rendering of the HTML and would require some changes to that part. So I decided to keep this simple and have it done sooner to help investigating timeout failures in our CI.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27574#pullrequestreview-3285362832