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