From haosun at openjdk.org  Fri Aug  1 00:04:02 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 00:04:02 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
Message-ID: <6CRZBpGwS69ZgWKLmIG7UOj9jPqVxvieJKEAT9lao-Y=.af3bdd20-0a45-4928-8c5b-197b377e8ba3@github.com>

On Wed, 30 Jul 2025 16:26:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Hao,
> 
> > Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> > Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.
> 
> Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

Thanks for your confirm, Jaikiran.
Forgot to mention that I tested `jdk_all, hotspot_all, langtools_all` with jtreg `8` and only found these two test failures.

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

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

From hannesw at openjdk.org  Fri Aug  1 08:38:00 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 1 Aug 2025 08:38:00 GMT
Subject: Integrated: 8294074: Make other specs more discoverable from the API
 docs
In-Reply-To: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
Message-ID: <jX3bwB4wULgs3fyizQxYvikDo-6Uyz7GnUsid3ZSquk=.6e6431a7-ad40-4161-bf9e-be5a13964ffb@github.com>

On Wed, 30 Jul 2025 10:51:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to the API overview page to make other specs more discoverable. The following sentence is added at the end of the overview text:
> 
>> [Related documents](https://cr.openjdk.org/~hannesw/8294074/docs.00/specs/index.html) specify the Java language, the Java virtual machine, various protocols and file formats pertaining to the Java platform, and tools included in the JDK.
> 
> The first sentence of the overview text is also rephrased.
> 
> The new API overview page [can be viewed here](https://cr.openjdk.org/~hannesw/8294074/docs.00/api/index.html).

This pull request has now been integrated.

Changeset: 7d63c9fa
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d63c9fa4d7d03c8565d0491e7ff93087b79cc39
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8294074: Make other specs more discoverable from the API docs

Reviewed-by: mr

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

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

From erikj at openjdk.org  Fri Aug  1 14:21:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 14:21:55 GMT
Subject: RFR: 8361142: Improve custom hooks for makefiles
In-Reply-To: <91cuhK8a2VHENkKujTT5Q7CYxYjnK8qV3jULeLXi9jU=.d12fe818-ca41-4448-8a8f-120c60a219d7@github.com>
References: <91cuhK8a2VHENkKujTT5Q7CYxYjnK8qV3jULeLXi9jU=.d12fe818-ca41-4448-8a8f-120c60a219d7@github.com>
Message-ID: <LDct7mydQZY1LYTfHKOT2etq934hYXRnVAPYQmtNt-I=.8cb7eb80-0b8d-491d-8fff-154c3e8ec15a@github.com>

On Tue, 1 Jul 2025 07:46:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add some additional and more fine-grained way in which custom makefiles can be integrated.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26060#pullrequestreview-3079432687

From erikj at openjdk.org  Fri Aug  1 17:23:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 17:23:56 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
Message-ID: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@github.com>

On Fri, 27 Jun 2025 16: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:
> 
>   Remove problemlisting

make/ModuleWrapper.gmk line 82:

> 80:     TARGETS += $(LAUNCHERS_LIST)
> 81:   endif
> 82: endif

I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:

$(LAUNCHER_LIST): $$($1)
TARGETS += $(LAUNCHER_LIST)


Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.

make/StaticLibs.gmk line 163:

> 161: # $2: The launcher name
> 162: define SetupRelauncher
> 163:   $1_$2_LAUNCHER_ARGS_LINE :=  $$(shell cat $$(SUPPORT_OUTPUTDIR)/static-native/relaunchers/$1/$2-relauncher-arguments.txt)

`$(call ReadFile, ...)`

also, double space?

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

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

From erik.joelsson at oracle.com  Fri Aug  1 17:54:56 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 1 Aug 2025 10:54:56 -0700
Subject: hotspot jtreg tests take WARNING_CFLAGS_JDK_CONLY flags
In-Reply-To: <AM9PR02MB6770334B693A05E91D313E619348A@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770334B693A05E91D313E619348A@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <6a386790-d220-4e7a-8fdb-f0ddaf421035@oracle.com>

Not sure about intended. The 'JDK' variable naming was introduced to 
basically mean not Hotspot. What flags that should apply to tests isn't 
always clear. I don't think that flags currently assigned to variables 
with JVM in the name should apply to hotspot tests. I think we just 
treat all native tests the same here and give them the JDK flags. This 
area could probably still need some careful sorting out and cleanup.

/Erik

On 7/10/25 08:23, Baesken, Matthias wrote:
>
> When? trying the GCC static analyzer (-fanalyzer flag)
>
> diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
>
> index e80d9a98957..9d1ae60047b 100644
>
> --- a/make/autoconf/flags-cflags.m4
>
> +++ b/make/autoconf/flags-cflags.m4
>
> @@ -610,7 +610,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
>
> ?? # CFLAGS WARNINGS STUFF
>
> ?? # Set JVM_CFLAGS warning handling
>
> ?? if test "x$TOOLCHAIN_TYPE" = xgcc; then
>
> - WARNING_CFLAGS_JDK_CONLY="$WARNINGS_ENABLE_ALL_CFLAGS"
>
> +??? # enable -fanalyzer (but better only for gcc12 + , and also only 
> for C)
>
> +??? # too many strange / shaky fd leak warnings
>
> +??? WARNING_CFLAGS_JDK_CONLY="-fanalyzer -Wno-analyzer-fd-leak 
> $WARNINGS_ENABLE_ALL_CFLAGS"
>
> WARNING_CFLAGS_JDK_CXXONLY="$WARNINGS_ENABLE_ALL_CXXFLAGS"
>
> WARNING_CFLAGS_JVM="$WARNINGS_ENABLE_ALL_CXXFLAGS"
>
> I noticed that the WARNING_CFLAGS_JDK_CONLY? go into the? hotspot?? 
> jtreg tests, e.g.? :
>
> /jdk/test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h:46:6: 
> error: dereference of NULL '0' [CWE-476] 
> [-Werror=analyzer-null-dereference]
>
> ?? 46 |?? *x = 34; // Crash
>
> ????? |?? ~~~^~~~
>
> ? 'dereference_null': event 1
>
> ??? |
>
> ??? |?? 46 |?? *x = 34; // Crash
>
> ??? |????? |?? ~~~^~~~
>
> ??? |????? |????? |
>
> ??? |????? |????? (1) dereference of NULL '0'
>
> This might be intended but?? I was surprised that the HS? C tests take 
> WARNING_CFLAGS_JDK_CONLY? ??!??? Is this intended or not ?
>
> Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250801/13911cd4/attachment-0001.htm>

From erikj at openjdk.org  Fri Aug  1 18:02:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:02:54 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented [v3]
In-Reply-To: <aT4-w8qplffs_oNEJaP0VPIY0lJhjoT4oEP_kB14E9U=.820028ff-3c6b-4544-aa32-67d26f82119c@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
 <aT4-w8qplffs_oNEJaP0VPIY0lJhjoT4oEP_kB14E9U=.820028ff-3c6b-4544-aa32-67d26f82119c@github.com>
Message-ID: <v3j22Vi0aPGA0cjyonQ0pK5YqKhuhQ4jI_I1yEHKc48=.b4f6294f-4df6-439b-8c1e-590b1480aaa7@github.com>

On Wed, 16 Jul 2025 18:52:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `open/doc/building.md` uses the incorrect `OEL6` keyword to denote the Oracle Enterprise Linux base OS distribution for Devkit ? replaced it with the correct one instead, i.e., `OL`.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update `doc/building.html

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26311#pullrequestreview-3080113895

From erikj at openjdk.org  Fri Aug  1 18:17:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:17:55 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <7-OHL7cQf8cKDTulwBLVf1DD6gIkSuX12P-TvbMvPa4=.736c0d91-a0cd-4cac-8d8c-251967742250@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

Marked as reviewed by erikj (Reviewer).

make/modules/jdk.compiler/Gensrc.gmk line 79:

> 77: 
> 78: ################################################################################
> 79: 

Can remove one of these comment delimiter lines.

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

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3080147875
PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2248577111

From erik.joelsson at oracle.com  Fri Aug  1 18:25:02 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 1 Aug 2025 11:25:02 -0700
Subject: JDK-8363942: Unable to make images after "make -t"
In-Reply-To: <IA0PPF8870D55A12B1311A446CEE3A06717CA25A@IA0PPF8870D55A1.namprd15.prod.outlook.com>
References: <IA0PPF8870D55A12B1311A446CEE3A06717CA25A@IA0PPF8870D55A1.namprd15.prod.outlook.com>
Message-ID: <f4faf27a-1538-4088-8ada-b9154f09b0f9@oracle.com>

On 7/29/25 08:16, Andrew Leonard wrote:
> Hi,
>
> I?m ?looking for help on resolving this bug please 
> (https://bugs.openjdk.org/browse/JDK-8363942), that we see building 
> Eclipse Temurin, whereby we build the ?exploded image(default)? 
> target, then externally ?sign? the binaries, then ?touch? the targets 
> using ?make -t? so they don?t get re-built, then build the ?images??
> However, after recent jdk-25 changes in idk-25+26 (I think by 
> 8349665), this process fails.
> We?ve found a workaround by manually deleting the file 
> ?create-main-targets-include? before calling make images, but that 
> doesn?t seem ideal.
>
I've never used `make -t` so I'm not surprised it doesn't work well with 
the OpenJDK build. We use a lot of meta targets and tricks throughout 
the build, and I would expect things to behave unexpectedly when using 
it. I'm curious why you think you need to run `make -t` after the 
signing procedure? As long as none of the signing operations are 
resetting the modification times on the signed binaries to an earlier 
timestamp than the build produced, and you didn't touch any other files 
or source files, then rebuilding shouldn't overwrite any of the already 
built or signed binaries. There can of course be bugs, and historically 
I'm sure there have been, causing things to be rebuilt unnecessarily, so 
with an approach like this I would definitely recommend adding a 
verification step after the build that checks all binaries for signatures.

Related to this, have you looked into 
https://bugs.openjdk.org/browse/JDK-8350801? It was meant to make 
external signing procedures easier to integrate with the build system.

/Erik

> Many thanks
> Andrew
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, 
> Winchester, Hampshire SO21 2JN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250801/64c14ea0/attachment-0001.htm>

From erikj at openjdk.org  Fri Aug  1 18:28:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:28:56 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26501#pullrequestreview-3080173442

From erikj at openjdk.org  Fri Aug  1 18:29:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:29:57 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <MYOxu1Y0X-cadUHNUOGHl-bo3zq3NFHzqr77RCG8i8g=.536325df-4118-449a-9fc1-b7a63673b25b@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3080178709

From vyazici at openjdk.org  Fri Aug  1 20:39:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 1 Aug 2025 20:39:00 GMT
Subject: Integrated: 8362244: Devkit's Oracle Linux base OS keyword is
 incorrectly documented
In-Reply-To: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
Message-ID: <r377uaEkJx-zd9WIgnc9br0xegqYOKl-DKKYWaSo7CE=.7490a240-4025-4e6d-95d3-8d22693c98fd@github.com>

On Tue, 15 Jul 2025 09:58:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `open/doc/building.md` uses the incorrect `OEL6` keyword to denote the Oracle Enterprise Linux base OS distribution for Devkit ? replaced it with the correct one instead, i.e., `OL`.

This pull request has now been integrated.

Changeset: 7ea08d39
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ea08d3928032aad05ce347272083a2be7d83546
Stats:     12 lines in 2 files changed: 0 ins; 2 del; 10 mod

8362244: Devkit's Oracle Linux base OS keyword is incorrectly documented

Reviewed-by: erikj

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

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

From aoqi at openjdk.org  Sat Aug  2 00:56:02 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Sat, 2 Aug 2025 00:56:02 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <o0Ql3pw0oWtpI_OUT-8p7JAT-6AWe-U6mPY68U2_Hks=.08b1a4e7-6987-40d3-8093-0bfe498d7555@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3146072074

From duke at openjdk.org  Sat Aug  2 00:56:02 2025
From: duke at openjdk.org (duke)
Date: Sat, 2 Aug 2025 00:56:02 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <L3qIK6l9NPuTc7f0KVZQfRdEIkfvTpcUQD0w9Fo5x94=.417b0c2f-76a5-4734-a384-10f55c4a5547@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

@theaoqi 
Your change (at version 2078e5eb1336ff4f00dccc1702c2c11df32bc266) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3146072490

From aoqi at openjdk.org  Mon Aug  4 07:22:54 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 07:22:54 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <cIW61FqCt8ZlKa-l-_4xI1bwQx1vR78UXSonKANecyI=.54fbb0cd-b3a9-46ff-ad51-9fe087c3987f@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Could any committer please help to sponsor this patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3149424916

From andrew.m.leonard at ibm.com  Mon Aug  4 08:27:54 2025
From: andrew.m.leonard at ibm.com (Andrew Leonard)
Date: Mon, 4 Aug 2025 08:27:54 +0000
Subject: JDK-8363942: Unable to make images after "make -t"
In-Reply-To: <f4faf27a-1538-4088-8ada-b9154f09b0f9@oracle.com>
References: <IA0PPF8870D55A12B1311A446CEE3A06717CA25A@IA0PPF8870D55A1.namprd15.prod.outlook.com>
 <f4faf27a-1538-4088-8ada-b9154f09b0f9@oracle.com>
Message-ID: <PH8PR15MB6181CAEA08FDC23B1094DAD3CA23A@PH8PR15MB6181.namprd15.prod.outlook.com>

Hi Erik,

Thank you for the suggestions. Yes, I agree make -t is not a great solution, and also confirm it?s odd even though the signed dylib?s timestamps are later, they get re-built.. which is probably a bug in itself. We do have a post build ?Sign Verification? job as you mention, which picks up these issues, which as you suggest is very useful and necessary.

JDK-8350801 I am aware of, I discussed  this with Frederic at the time as being useful. However, at the moment the difficulty is calling out from a GNU make file at one of these ?exit? points to be able to call a Jenkins Job to do the signing. Unfortunately, as it stands we have to use an Eclipse Signing Jenkins job running on a secure remote node, so we have to call out to this specific Jenkins job, which is very difficult to do from a GNU make file. There is potential for us to raise an Eclipse feature request for an alternative API for us, which could be used in this environment.

I am going to do some more investigation into why the dylib?s get rebuilt after signing, as if we could remove the ?make -t? hack then that would be ideal. I am guessing maybe there are some ?rules? that need a tweak or two.

Many thanks,
Andrew


Sent from Outlook for Mac

From: Erik Joelsson <erik.joelsson at oracle.com>
Date: Friday, 1 August 2025 at 19:25
To: Andrew Leonard <andrew.m.leonard at ibm.com>, build-dev at openjdk.org <build-dev at openjdk.org>
Subject: [EXTERNAL] Re: JDK-8363942: Unable to make images after "make -t"

This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!99FRstz4eM87H9bZrkThkmJt0DkNhWht5MerKiEHaAwuctiV9aTiMgyU5E2Ls-V383lAHpH2hSPmTTkKwZJSQdvR4C1ktVx9W95NGg$>

On 7/29/25 08:16, Andrew Leonard wrote:
Hi,

I?m  looking for help on resolving this bug please (https://bugs.openjdk.org/browse/JDK-8363942<https://bugs.openjdk.org/browse/JDK-8363942 >), that we see building Eclipse Temurin, whereby we build the ?exploded image(default)? target, then externally ?sign? the binaries, then ?touch? the targets using ?make -t? so they don?t get re-built, then build the ?images??
However, after recent jdk-25 changes in idk-25+26 (I think by 8349665), this process fails.
We?ve found a workaround by manually deleting the file ?create-main-targets-include? before calling make images, but that doesn?t seem ideal.


I've never used `make -t` so I'm not surprised it doesn't work well with the OpenJDK build. We use a lot of meta targets and tricks throughout the build, and I would expect things to behave unexpectedly when using it. I'm curious why you think you need to run `make -t` after the signing procedure? As long as none of the signing operations are resetting the modification times on the signed binaries to an earlier timestamp than the build produced, and you didn't touch any other files or source files, then rebuilding shouldn't overwrite any of the already built or signed binaries. There can of course be bugs, and historically I'm sure there have been, causing things to be rebuilt unnecessarily, so with an approach like this I would definitely recommend adding a verification step after the build that checks all binaries for signatures.

Related to this, have you looked into https://bugs.openjdk.org/browse/JDK-8350801<https://bugs.openjdk.org/browse/JDK-8350801 >? It was meant to make external signing procedures easier to integrate with the build system.

/Erik

Many thanks
Andrew
Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250804/65bfa996/attachment-0001.htm>

From aoqi at openjdk.org  Mon Aug  4 12:40:04 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 12:40:04 GMT
Subject: Integrated: 8364177: JDK fails to build due to undefined symbol in
 libpng on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <gcE667FP9P6GmTsgDrIDuWuzCn9V6l6A1R7LWZ_aqkQ=.e73a231c-6e4d-46de-839e-25990f1c7ea0@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

This pull request has now been integrated.

Changeset: a9f3d3a2
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9f3d3a290060f98967feaad2fa03ef077a64534
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8364177: JDK fails to build due to undefined symbol in libpng on LoongArch64

Reviewed-by: prr, aivanov, erikj

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

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

From aoqi at openjdk.org  Mon Aug  4 13:14:13 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 13:14:13 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>
Message-ID: <nE0oshLhf9J_xSlT2doxkLirAD2qLkXFLKzry-d-9UE=.79484802-5e8b-4131-a1d5-bb5a4a685980@github.com>

On Fri, 1 Aug 2025 18:26:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> Marked as reviewed by erikj (Reviewer).

@erikj79, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3150658075

From cstein at openjdk.org  Tue Aug  5 16:03:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 5 Aug 2025 16:03:07 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <1XRUup7RXkUWm_2yscYV2M-m4ooHr70QdwcVVB7zxDI=.d641c6f9-9dd9-4da7-8599-a164274b9d93@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Both tests seem to make hard assumptions on where binary files of `@library` classes are stored.

- [TestSPISigned.java#L60-L62](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java#L60-L62)
- [resexhausted003.java#L83-L96](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003.java#L83-L96)

The storage location changed due to https://bugs.openjdk.org/browse/CODETOOLS-7902847 - it might change again in the near future. Thus, both tests need to be updated to work correctly without relying on a specific location of compiled library classes.

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

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

From jwilhelm at openjdk.org  Tue Aug  5 17:37:57 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 5 Aug 2025 17:37:57 GMT
Subject: [jdk25] RFR: 8364038: Remove EA from the JDK 25 version string with
 first RC promotion
Message-ID: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>

Removing EA from the version string.

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

Commit messages:
 - 8364038: Remove EA from the JDK 25 version string with first RC promotion

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

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

From mikael at openjdk.org  Tue Aug  5 17:37:57 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 5 Aug 2025 17:37:57 GMT
Subject: [jdk25] RFR: 8364038: Remove EA from the JDK 25 version string
 with first RC promotion
In-Reply-To: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
References: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
Message-ID: <hjeAuTIUEm0bif9YbbWcW4dv7ZWDmyGF-ERWJlTrMhE=.c9bad4a4-accb-4661-9004-e4a7e796e711@github.com>

On Tue, 5 Aug 2025 17:28:04 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removing EA from the version string.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26647#pullrequestreview-3089140874

From erikj at openjdk.org  Tue Aug  5 17:56:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Aug 2025 17:56:07 GMT
Subject: [jdk25] RFR: 8364038: Remove EA from the JDK 25 version string
 with first RC promotion
In-Reply-To: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
References: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
Message-ID: <LjTPfcZgLgIwQqBG-096aKBHf5Xom9nsoIO1bdDn1OQ=.5574d966-fe0f-4e6e-a38a-e1cf6d29db96@github.com>

On Tue, 5 Aug 2025 17:28:04 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removing EA from the version string.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26647#pullrequestreview-3089193365

From iris at openjdk.org  Tue Aug  5 18:10:03 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Aug 2025 18:10:03 GMT
Subject: [jdk25] RFR: 8364038: Remove EA from the JDK 25 version string
 with first RC promotion
In-Reply-To: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
References: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
Message-ID: <nH4Z-dMcYGJveX6xFaeRsjHkS4RVvVegVo46CP-jFLc=.e38335fd-8fe0-473d-8b94-92c4f4eb4d52@github.com>

On Tue, 5 Aug 2025 17:28:04 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removing EA from the version string.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26647#pullrequestreview-3089230312

From cstein at openjdk.org  Tue Aug  5 19:31:05 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 5 Aug 2025 19:31:05 GMT
Subject: [jdk25] RFR: 8364038: Remove EA from the JDK 25 version string
 with first RC promotion
In-Reply-To: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
References: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
Message-ID: <uC9QDIKPfYBJZ-e9x8qf6hSbc_sPW6b0cMAlZDssr2Y=.08a27ef0-e8e2-46f2-a595-8282b02180f7@github.com>

On Tue, 5 Aug 2025 17:28:04 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removing EA from the version string.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26647#pullrequestreview-3089445914

From jwilhelm at openjdk.org  Tue Aug  5 23:20:09 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 5 Aug 2025 23:20:09 GMT
Subject: [jdk25] Integrated: 8364038: Remove EA from the JDK 25 version string
 with first RC promotion
In-Reply-To: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
References: <mWKNNjIcCUNj-QXVdLzLvOzOAkPHIAcW126l4aaEHvQ=.e170cdb1-63d6-43be-b265-8f3ba9bda9d1@github.com>
Message-ID: <vpkl7bOuQkKRAbagIKNJAJ7NFR6JloNW-kAYJYB9vzo=.4c677009-9370-464c-99dd-713120874368@github.com>

On Tue, 5 Aug 2025 17:28:04 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removing EA from the version string.

This pull request has now been integrated.

Changeset: 73c28c2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73c28c2e3dc08f263be4c537c09c2763b87ca122
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8364038: Remove EA from the JDK 25 version string with first RC promotion

Reviewed-by: mikael, erikj, iris, cstein

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

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

From stuefe at openjdk.org  Wed Aug  6 05:41:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Aug 2025 05:41:38 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
Message-ID: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>

A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.

The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.

See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .

The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

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

Commit messages:
 - tolerate sigaction failing
 - Fixes
 - fix
 - start+repro-case

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

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

From erikj at openjdk.org  Wed Aug  6 12:25:05 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 12:25:05 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Build changes look trivially good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3092284286

From rriggs at openjdk.org  Wed Aug  6 14:20:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 14:20:04 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

src/java.base/unix/native/libjava/childproc.c line 429:

> 427:     }
> 428: 
> 429:     // Childs should be started with default signal disposition for SIGPIPE

Editorial: "Childs" -> Children for plural, "Child" for singular.  Here and in tests.

test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 60:

> 58:         struct sigaction act;
> 59:         if (sigaction(signals[n].sig, NULL, &act) != 0) {
> 60:             perror("sigaction");

The sigaction error message goes to stderr, so it is does not appear in line with the signal name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257297399
PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2257335209

From duke at openjdk.org  Wed Aug  6 19:34:36 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Wed, 6 Aug 2025 19:34:36 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
Message-ID: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>

https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212

In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).

All the Windows gtests now pass with this change.

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

Commit messages:
 - Disable structured exception handling in gtests on Windows

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

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

From erikj at openjdk.org  Wed Aug  6 21:52:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 21:52:18 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <2pCKvDxDkjNa0545s8fB_4S8u_ARV8U9xrTKB1xEPMg=.7cfa4b5f-2838-47bf-8274-885544db4424@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

>From a build/makefile point of view, this looks fine, but I would like input from someone more familiar with GTest as well.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26661#pullrequestreview-3094426151

From kbarrett at openjdk.org  Thu Aug  7 00:27:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 7 Aug 2025 00:27:14 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

How is it that we (Oracle) don't see these gtest death test failures in our
CI? I'm guessing others (like SAP - @tstuefe  ?) aren't either, since this
issue is newly reported while the causing change was made more than 8 months
ago.

The code in gtest-death-test-internal.h#L198-L212 referenced in the PR
description is conditionalized on GTEST_HAS_EXCEPTIONS, which leads me to
wonder why exceptions are enabled. If not for that, we wouldn't be in that
code.

That led me to wonder why, on Windows, we build libgtest and rebuild libjvm
with exceptions enabled, by using -EHsc instead of no -EH option as done for
the non-gtest libjvm?

https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L71
https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L101

That decision seems pretty old, like maybe from the initial introduction of
gtest. I haven't tracked down why, or whether the reasons are still valid. I
think it would be better to change that, assuming that's possible.

I was concerned that this might effectively undo JDK-8185734, since the
suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true.
But it looks like the actual change didn't do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3162014034

From rriggs at openjdk.org  Thu Aug  7 01:32:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 01:32:22 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <OHLCsMhBRugETXAn_zrDg4xtlWmdpDF-iCfa-75wmg4=.cc14a862-4442-474c-9a22-a09edf44e14b@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

While you're looking at childproc.c, can you update the comment at line 375 that references "closeDescriptors".
It got missed.  There's a separate bug for that [JDK-8364822](https://bugs.openjdk.org/browse/JDK-8364822) but if its convenient to fix.  tnx

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3162123827

From stuefe at openjdk.org  Thu Aug  7 05:41:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 05:41:45 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

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

  Feedback Roger

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26615/files
  - new: https://git.openjdk.org/jdk/pull/26615/files/b607b252..fa1be838

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

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

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

From lmesnik at openjdk.org  Thu Aug  7 05:54:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 05:54:53 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode
Message-ID: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>

The fix added JVMTI stress testing mode.

This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.

I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.

The agent has 2 modes now:
 - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
 - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 

The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
Note, that flagless tests are excluded automatically and not executed in this mode.

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

Commit messages:
 - problemlist and exclusion fiexd.
 - fixed IR framework
 - Merge branch 'master' of https://github.com/openjdk/jdk into jvmti-stress-agent
 - fixed small issues
 - Revert "updated struct to c++"
 - Merge branch 'master' of https://github.com/openjdk/jdk into jvmti-stress-agent
 - fixed vm death
 - updated struct to c++
 - lib updated
 - more fixes
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7e484e2a...cb9c6457

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

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

From stuefe at openjdk.org  Thu Aug  7 06:09:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:09:15 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <o9Yju5ZTNSqqICUfgspQYnm_paOYJhYEunhas2FXv3I=.cd59d9cf-c336-474a-b85b-7324302e5b03@github.com>
Message-ID: <_PzM_ySKqe40uJn5ZhSXJdVJ80J-Us8UbT0GGJW5lRw=.65632516-5765-41c8-b962-311f1351eb38@github.com>

On Thu, 7 Aug 2025 05:41:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Roger

@RogerRiggs Thanks for your review! Addressed in update.

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3162632014

From stuefe at openjdk.org  Thu Aug  7 06:09:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:09:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v2]
In-Reply-To: <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <wKIBeQ_VaoW_m2xBHhSmmXAAlQI31sgsyOcJIQxOuL4=.8d534cea-484f-4ceb-bb55-bc66e84a0fa5@github.com>
Message-ID: <0Q7gCa7CWceJqA7LCN3wxmWhVvxstuGGOzRBPKEGNkI=.396ad6ec-1650-426f-bf49-9b46c3f91453@github.com>

On Wed, 6 Aug 2025 14:04:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback Roger
>
> src/java.base/unix/native/libjava/childproc.c line 429:
> 
>> 427:     }
>> 428: 
>> 429:     // Childs should be started with default signal disposition for SIGPIPE
> 
> Editorial: "Childs" -> Children for plural, "Child" for singular.  Here and in tests.

Fixed

> test/jdk/java/lang/ProcessBuilder/childSignalDisposition/exePrintSignalDisposition.c line 60:
> 
>> 58:         struct sigaction act;
>> 59:         if (sigaction(signals[n].sig, NULL, &act) != 0) {
>> 60:             perror("sigaction");
> 
> The sigaction error message goes to stderr, so it is does not appear in line with the signal name.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2259171437
PR Review Comment: https://git.openjdk.org/jdk/pull/26615#discussion_r2259171720

From stuefe at openjdk.org  Thu Aug  7 06:54:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Aug 2025 06:54:42 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

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

  fix comments about closeDescriptors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26615/files
  - new: https://git.openjdk.org/jdk/pull/26615/files/fa1be838..38648cb4

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

  Stats: 29 lines in 4 files changed: 9 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26615/head:pull/26615

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

From erikj at openjdk.org  Thu Aug  7 13:20:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 13:20:20 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>

On Thu, 17 Jul 2025 02:39:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

make/RunTests.gmk line 64:

> 62: 
> 63: AGENT_PREFIX := lib
> 64: AGENT_EXT := .so

We already have `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` defined in spec.gmk. To make those available in a test prebuilt scenario, they need to also be defined in RunTestPrebuiltSpec.gmk. Then you can use those instead of defining these.

make/RunTests.gmk line 215:

> 213: $(eval $(call ParseKeywordVariable, JTREG, \
> 214:     SINGLE_KEYWORDS := JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT \
> 215:         TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY JVMTI_STRESS_AGENT MAX_MEM RUN_PROBLEM_LISTS \

Could you add this list element in a way that doesn't make the lines any longer?

make/RunTests.gmk line 892:

> 890:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 891: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 892:     ))

Please use regular parentheses when referencing variables in makefiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260294410
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260298782
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2260294596

From rriggs at openjdk.org  Thu Aug  7 14:20:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Aug 2025 14:20:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
Message-ID: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>

On Thu, 7 Aug 2025 06:54:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments about closeDescriptors

It looks like I created a merge conflict by asking to fix these.  
Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started).
The least chaos may be created by backing out those changes from this PR.  (Unless you like your words better than PR#26667).

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3164396666

From duke at openjdk.org  Thu Aug  7 16:55:48 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 16:55:48 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on
 current frequency
Message-ID: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>

In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.

These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.


linux-x64 GCC
master      real 81.39 user 3352.15 sys 287.49
JDK-8365053 real 81.94 user 3030.24 sys 295.82

linux-x64 Clang
master      real 43.44 user 2082.93 sys 130.70
JDK-8365053 real 38.44 user 1723.80 sys 117.68

linux-aarch64 GCC
master      real 1188.08 user 2015.22 sys 175.53
JDK-8365053 real 1019.85 user 1667.45 sys 171.86

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

Commit messages:
 - refresh

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

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

From shade at openjdk.org  Thu Aug  7 17:10:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Aug 2025 17:10:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <G98a7-6xw9dd61VHpDwhhCYOQph_iHgwPRMN4532KaQ=.5a8d8799-f579-46f6-8c3e-f2ce75689bc1@github.com>

On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86

src/hotspot/share/precompiled/precompiled.hpp line 29:

> 27: 
> 28: // These header files are included in at least 130 C++ files, as of
> 29: // measurements made in November 2018. This list excludes files named

Keep this comment, just update the date (seeing how threshold is the same?).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2260927049

From duke at openjdk.org  Thu Aug  7 17:18:16 2025
From: duke at openjdk.org (Daniel Hu)
Date: Thu, 7 Aug 2025 17:18:16 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v4]
In-Reply-To: <CcbJWdSwy7zaEE1E9KSPvO8HlF66465Ox8xu_6QhYAU=.c46723f7-fce6-49cf-9ae6-1053f7c942af@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
 <CcbJWdSwy7zaEE1E9KSPvO8HlF66465Ox8xu_6QhYAU=.c46723f7-fce6-49cf-9ae6-1053f7c942af@github.com>
Message-ID: <87aN_24_hPMJkFOh3XQHRXmVO2iRz08jODDYvjCpVOs=.2e911345-04af-4709-9dac-0a2169e6b388@github.com>

On Wed, 9 Jul 2025 22:28:56 GMT, Daniel Hu <duke at openjdk.org> wrote:

>> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.
>
> Daniel Hu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341735
>  - redid byte matching which should fix cross chunk strings
>  - style improvements
>  - remove 8341024
>  - remove trailing whitespace
>  - fix

I'll push another update soon to fix the speed issue

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

PR Comment: https://git.openjdk.org/jdk/pull/26030#issuecomment-3165089009

From duke at openjdk.org  Thu Aug  7 17:24:13 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Thu, 7 Aug 2025 17:24:13 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
Message-ID: <qUPML-lEFJVgboVDwt3u1us3UppQx2uWDykWTJcHj8E=.12f2b43f-8e49-4210-8eec-793ea6786571@github.com>

On Thu, 7 Aug 2025 00:24:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> The code in gtest-death-test-internal.h#L198-L212 referenced in the PR description is conditionalized on GTEST_HAS_EXCEPTIONS, which leads me to wonder why exceptions are enabled. If not for that, we wouldn't be in that code.
> 
> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
> 
> https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L71 https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L101
> 
> That decision seems pretty old, like maybe from the initial introduction of gtest. I haven't tracked down why, or whether the reasons are still valid. I think it would be better to change that, assuming that's possible.

This warning from the C++ compiler (after removing the 2 -EHsc lines) indicates that gtest code is using C++ exception handling:


c:\progra~1\mib055~1\2022\enterprise\vc\tools\msvc\14.44.35207\include__msvc_ostream.hpp(781): error C2220: the following warning is treated as an error
c:\progra~1\mib055~1\2022\enterprise\vc\tools\msvc\14.44.35207\include__msvc_ostream.hpp(781): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
c:\progra~1\mib055~1\2022\enterprise\vc\tools\msvc\14.44.35207\include__msvc_ostream.hpp(781): note: the template instantiation context (the oldest one first) is
c:\repos\googletest\googletest\include\gtest/gtest-message.h(118): note: see reference to function template instantiation 'std::basic_ostream<char,std::char_traits<char>> &std::operator <<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,const char *)' being compiled

> How is it that we (Oracle) don't see these gtest death test failures in our CI? I'm guessing others (like SAP - @tstuefe ?) aren't either, since this issue is newly reported while the causing change was made more than 8 months ago.
> 

Should gtests be enabled in the pre-checkin GitHub actions to prevent regressions? I think they take a few minutes to execute.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3165102917
PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3165108189

From duke at openjdk.org  Thu Aug  7 17:28:14 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Thu, 7 Aug 2025 17:28:14 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
Message-ID: <YJicK0BIdXfrLqTuq9v0l5A-iM1BOctGVVn5xOi0i5I=.82be9fbd-139f-474f-83c9-4ace8a52e091@github.com>

On Thu, 7 Aug 2025 00:24:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.

Thanks for pointing this out. Let me investigate.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3165116409

From shade at openjdk.org  Thu Aug  7 17:35:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Aug 2025 17:35:17 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>

On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86

Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils. It would be nice if the output of that script could be simply piped into `precompiled.hpp`, so we can use it later without extra work.

We can, technically, hook it up a similar way SortIncludes.java is currently done, but I think it is unnecessary at this point. In a perfect world we would not be needing precompiled headers. In less ideal world, having a jtreg test that warns us that a new popular header appeared, or that older header is not as popular anymore, would be handy. Again, this is something out of scope for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165135998

From shade at openjdk.org  Thu Aug  7 18:03:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Aug 2025 18:03:14 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <NdjY9XINdOfYMSaCld55g6BZtWuBLjidRsPm2HXN9zE=.030b9b6e-bddf-4c23-8c18-8306601c2c5d@github.com>

On Thu, 7 Aug 2025 16:47:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86

On my M1, with some AV software that always get in the way, I am seeing 15% faster build, which saves about half a minute. This is great!


CONF=macosx-aarch64-server-fastdebug LOG=info make hotspot  
1245.30s user 230.07s system 640% cpu 3:50.49 total

CONF=macosx-aarch64-server-fastdebug LOG=info make hotspot  
1064.59s user 203.24s system 618% cpu 3:20.09 total

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165209211

From duke at openjdk.org  Thu Aug  7 18:51:04 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 18:51:04 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v2]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <HvxXFqmtYykIyWyG9HQq4RYAlBF0LnRlf8K3rUO2J64=.f7c93fc3-10e7-41ed-87ba-f14040e84a8b@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86

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

  keep comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/9e0cb7e8..a75494f1

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

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

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

From duke at openjdk.org  Thu Aug  7 18:51:05 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 18:51:05 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v2]
In-Reply-To: <G98a7-6xw9dd61VHpDwhhCYOQph_iHgwPRMN4532KaQ=.5a8d8799-f579-46f6-8c3e-f2ce75689bc1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <G98a7-6xw9dd61VHpDwhhCYOQph_iHgwPRMN4532KaQ=.5a8d8799-f579-46f6-8c3e-f2ce75689bc1@github.com>
Message-ID: <pveg3yPSOwFnCWnsYLxHKPhdh6akdivJtiVnLEuGoQo=.87c38131-bc89-469b-adb9-85092ea756d4@github.com>

On Thu, 7 Aug 2025 17:07:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep comment
>
> src/hotspot/share/precompiled/precompiled.hpp line 29:
> 
>> 27: 
>> 28: // These header files are included in at least 130 C++ files, as of
>> 29: // measurements made in November 2018. This list excludes files named
> 
> Keep this comment, just update the date (seeing how threshold is the same?).

The part about `.inline.hpp` is not relevant anymore though, I've seen significant improvements after including a couple of them. I'll keep the rest.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261151719

From duke at openjdk.org  Thu Aug  7 18:51:06 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 18:51:06 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v2]
In-Reply-To: <pveg3yPSOwFnCWnsYLxHKPhdh6akdivJtiVnLEuGoQo=.87c38131-bc89-469b-adb9-85092ea756d4@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <G98a7-6xw9dd61VHpDwhhCYOQph_iHgwPRMN4532KaQ=.5a8d8799-f579-46f6-8c3e-f2ce75689bc1@github.com>
 <pveg3yPSOwFnCWnsYLxHKPhdh6akdivJtiVnLEuGoQo=.87c38131-bc89-469b-adb9-85092ea756d4@github.com>
Message-ID: <soDpkf0fVqumZtNI5Xqseq6z5_6_71hWz978ylRCPTQ=.0e3ca8e6-695f-4de0-a5e9-44634d1cac1e@github.com>

On Thu, 7 Aug 2025 18:44:29 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/hotspot/share/precompiled/precompiled.hpp line 29:
>> 
>>> 27: 
>>> 28: // These header files are included in at least 130 C++ files, as of
>>> 29: // measurements made in November 2018. This list excludes files named
>> 
>> Keep this comment, just update the date (seeing how threshold is the same?).
>
> The part about `.inline.hpp` is not relevant anymore though, I've seen significant improvements after including a couple of them. I'll keep the rest.

a75494f10f47a032f01e7e967c3b937166d8780d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261153641

From erikj at openjdk.org  Thu Aug  7 19:54:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 19:54:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v2]
In-Reply-To: <HvxXFqmtYykIyWyG9HQq4RYAlBF0LnRlf8K3rUO2J64=.f7c93fc3-10e7-41ed-87ba-f14040e84a8b@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <HvxXFqmtYykIyWyG9HQq4RYAlBF0LnRlf8K3rUO2J64=.f7c93fc3-10e7-41ed-87ba-f14040e84a8b@github.com>
Message-ID: <xe7QxakUj5zywz-kqbsbswdLLrBzIvN48HvOCQcw0KE=.dbd16777-b571-46fd-a5b5-d6388ae82c3c@github.com>

On Thu, 7 Aug 2025 18:51:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep comment

I tried it on Windows. Build time for hotspot was basically the same before and after, so no regression at least. So I'm fine with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165525209

From duke at openjdk.org  Thu Aug  7 20:00:14 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 7 Aug 2025 20:00:14 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
Message-ID: <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>

On Thu, 7 Aug 2025 17:32:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils. It would be nice if the output of that script could be simply piped into `precompiled.hpp`, so we can use it later without extra work.
> 
> We can, technically, hook it up a similar way SortIncludes.java is currently done, but I think it is unnecessary at this point. In a perfect world we would not be needing precompiled headers. In less ideal world, having a jtreg test that warns us that a new popular header appeared, or that older header is not as popular anymore, would be handy. Again, this is something out of scope for this PR.

I'll add the generation script, it looks like something that could be useful at some point in the future. I think there should be a human curator though, because the process is not completely automatic. For example, when the threshold is set to 50 I get this compilation error:

/jdk/src/hotspot/share/compiler/compilerEvent.cpp:59:36: error: redefinition of 'phase_names' with a different type: 'GrowableArray<const char *> *' vs 'const char *[100]'
static GrowableArray<const char*>* phase_names = nullptr;
                                   ^
/jdk/src/hotspot/share/opto/phasetype.hpp:147:20: note: previous definition is here
static const char* phase_names[] = {


It could happen with any threshold, even 130 as the codebase evolves.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3165535039

From asemenyuk at openjdk.org  Thu Aug  7 20:14:30 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Aug 2025 20:14:30 GMT
Subject: RFR: 8364129: Rename libwixhelper
Message-ID: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>

Rename "libwixhelper" in "libmsica".

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

Commit messages:
 - 8364129: Rename libwixhelper

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

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

From erikj at openjdk.org  Thu Aug  7 20:21:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 20:21:10 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <DUa_B_ygYgZsHBD3d3wRKPfZNG4ZrTuTdRm4sqSyHaw=.d7368d5b-0d0f-43bc-aa51-9cf8dd0f317d@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3098606661

From almatvee at openjdk.org  Thu Aug  7 20:48:12 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 7 Aug 2025 20:48:12 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:

> 1: /*

Should we rename directory name as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261362214

From erikj at openjdk.org  Thu Aug  7 21:11:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 21:11:12 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
Message-ID: <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>

On Thu, 7 Aug 2025 20:45:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:
> 
>> 1: /*
> 
> Should we rename directory name as well?

Without renaming the directory, I'm wondering how this could build at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261397039

From lmesnik at openjdk.org  Thu Aug  7 22:18:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 22:18:43 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  makefiles fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/cb9c6457..6d505a8b

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

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

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

From lmesnik at openjdk.org  Thu Aug  7 22:18:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 7 Aug 2025 22:18:44 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <6i_NUjWgiZ71wdex51k2-J86RrWhOeb7T4Z1qHxq_9g=.3cf3fbeb-6953-4eb7-a988-62bc750136c0@github.com>
Message-ID: <1kiR2G4snYm5hhiyTqxz_YmmR0X7-VmLWbnSQuSc_XM=.ec06f4bc-d465-4364-a8d1-f223762e2b84@github.com>

On Thu, 7 Aug 2025 13:14:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   makefiles fixed
>
> make/RunTests.gmk line 64:
> 
>> 62: 
>> 63: AGENT_PREFIX := lib
>> 64: AGENT_EXT := .so
> 
> We already have `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` defined in spec.gmk. To make those available in a test prebuilt scenario, they need to also be defined in RunTestPrebuiltSpec.gmk. Then you can use those instead of defining these.

Thanks for suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2261561101

From duke at openjdk.org  Fri Aug  8 00:43:27 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 00:43:27 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

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

  script. update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/a75494f1..d6cd068b

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

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

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

From asemenyuk at openjdk.org  Fri Aug  8 01:06:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 01:06:19 GMT
Subject: RFR: 8364129: Rename libwixhelper
In-Reply-To: <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
 <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
Message-ID: <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>

On Thu, 7 Aug 2025 21:08:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> src/jdk.jpackage/windows/native/libwixhelper/libmsica.cpp line 1:
>> 
>>> 1: /*
>> 
>> Should we rename directory name as well?
>
> Without renaming the directory, I'm wondering how this could build at all.

Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2261727643

From qamai at openjdk.org  Fri Aug  8 03:10:12 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 03:10:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
Message-ID: <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com>

On Fri, 8 Aug 2025 00:43:27 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   script. update

src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 73:

> 71:             paths.filter(Files::isRegularFile)
> 72:                     .filter(path -> {
> 73:                         String name = path.getFileName().toString();

IIUC this means that we count the number of cpp or hpp files that directly include a file, but should we count the number of cpp file that directly or transitively include a file instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2261838083

From dholmes at openjdk.org  Fri Aug  8 04:57:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Aug 2025 04:57:16 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
 <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
Message-ID: <JqmB0VEJQOXUqDUyin1nAe7PmiaHHayrW73ZhjtyCY0=.14a5018c-04cf-4276-833a-2b0e2e34073a@github.com>

On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> For example, when the threshold is set to 50 I get this compilation error:

How can we possibly get a compilation error when everything should build with PCH disabled?

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3166572069

From stuefe at openjdk.org  Fri Aug  8 05:25:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 05:25:02 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - merge
 - fix comments about closeDescriptors
 - Feedback Roger
 - tolerate sigaction failing
 - Fixes
 - fix
 - start+repro-case

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

Changes: https://git.openjdk.org/jdk/pull/26615/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26615&range=03
  Stats: 196 lines in 5 files changed: 195 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26615/head:pull/26615

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

From stuefe at openjdk.org  Fri Aug  8 05:25:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 05:25:02 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
 <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
Message-ID: <8ow-rAWzGKO5n8jjb63h28wf-woWRT04Z0L1vI1qWgM=.0ccb6e34-75b6-42b3-aee5-40d1085e5a16@github.com>

On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It looks like I created a merge conflict by asking to fix these. Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started). The least chaos may be created by backing out those changes from this PR. (Unless you like your words better than PR#26667).

Okay, I removed my comments again.

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3166614792

From stuefe at openjdk.org  Fri Aug  8 05:47:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 05:47:18 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <uCf-74bbT6J1DKIr9EpRitcmqxm3c61HnE9Np4mtKv4=.7c1309b6-1381-4944-a466-37e3ceffef64@github.com>
Message-ID: <LG_1sWkO9HpruwfjB7zLTcBYMN9ylpAhQ8ifCzsRbKQ=.922a0bfe-3cdb-41fa-99db-43325f2738c6@github.com>

On Thu, 7 Aug 2025 00:24:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> How is it that we (Oracle) don't see these gtest death test failures in our CI? I'm guessing others (like SAP - @tstuefe ?) aren't either, since this issue is newly reported while the causing change was made more than 8 months ago.
> 
> The code in gtest-death-test-internal.h#L198-L212 referenced in the PR description is conditionalized on GTEST_HAS_EXCEPTIONS, which leads me to wonder why exceptions are enabled. If not for that, we wouldn't be in that code.
> 
> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
> 
> https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L71 https://github.com/openjdk/jdk/blame/f95af744b07a9ec87e2507b3d584cbcddc827bbd/make/hotspot/lib/CompileGtest.gmk#L101
> 
> That decision seems pretty old, like maybe from the initial introduction of gtest. I haven't tracked down why, or whether the reasons are still valid. I think it would be better to change that, assuming that's possible.
> 
> I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.

This all sounds very familiar; let me check.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3166646532

From stuefe at openjdk.org  Fri Aug  8 06:33:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 06:33:09 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

So, we run gtests on Windows with `--gtest_catch_exceptions=0` which disables the inbuilt exception handler.

See issues 
- https://bugs.openjdk.org/browse/JDK-8185734  
- https://bugs.openjdk.org/browse/JDK-8267138 (fixed an oversight in 8185734)

See more details in my [PR description for 8185734](https://github.com/openjdk/jdk/pull/1757#issue-765285610), that's why this all sounded so familiar.

The mechanism in place since 8267138 should be enough for my understanding. @swesonga, can you find out why this is not sufficient in your case? Is this option not passed on to your test?

> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?

In the libjvm code itself, we don't use C++ exceptions, and we catch all Windows SEH with `__try`/`__except`. We also don't want standard stack unwinding with these signals. So no need for `/EHxx`. My assumption is that the gtest framework itself uses C++ exceptions and therefore needs `/EHsc`. The documentation is not super clear on some aspects of this (https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model), but it says that for standard C++ exceptions to work `/EHsc` is needed.

> I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.

In my PR for 8184734, I wrote: 

" In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream."

So it looks this was the first thing I tried back then, and it failed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3166724727

From kbarrett at openjdk.org  Fri Aug  8 06:36:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Aug 2025 06:36:19 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
Message-ID: <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>

On Fri, 8 Aug 2025 00:43:27 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   script. update

Changes requested by kbarrett (Reviewer).

src/hotspot/share/precompiled/precompiled.hpp line 29:

> 27: 
> 28: // These header files are included in at least 130 C++ files, as of
> 29: // measurements made in August 2025.

I don't think there's anything particularly special about the number 130.

Another thing to consider when a header file has a high include count is
whether it's being overincluded. We've had lots of those, and some folks
occasionally try to poke at that problem. Some of the removals here look like
they might be a result of such efforts.

Still another thing to consider is the cost of inclusion. Some files may just
be a lot more expensive to process and benefit more for being precompiled.
File size can be an indicator, but there are others. Unfortunately, I don't
know of a good way to measure this.

src/hotspot/share/precompiled/precompiled.hpp line 70:

> 68: #include "utilities/ticks.hpp"
> 69: 
> 70: #ifdef TARGET_COMPILER_visCPP

All of the reported testing was on Linux. These were included specifically because measurements
said their inclusion here was beneficial. And my recollection from previous discussions is that
Visual Studio may be the compiler where precompiled headers are most beneficial.

src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70:

> 68:         // Count inclusion times for each header
> 69:         Map<String, Integer> occurrences = new HashMap<>();
> 70:         try (Stream<Path> paths = Files.walk(hotspotPath)) {

I think walking the source tree is the wrong approach to gathering the data
about include counts. I think better is to do a build and then look at the
files <builddir>/hotspot/variant-server/libjvm/objs/*.d. From that one can build
a completely accurate count of the transitive inclusions.

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

PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3099600154
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262050884
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262055386
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262041141

From stuefe at openjdk.org  Fri Aug  8 06:44:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 06:44:12 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>
Message-ID: <o5nsYUPwnopDUaWo5yB3CTyxBEX77bihUVdMdOjD36M=.d26ec23e-7c21-45f3-b7ec-ae5a595c21e4@github.com>

On Fri, 8 Aug 2025 06:30:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
>> 
>> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
>> 
>> All the Windows gtests now pass with this change.
>
> So, we run gtests on Windows with `--gtest_catch_exceptions=0` which disables the inbuilt exception handler.
> 
> See issues 
> - https://bugs.openjdk.org/browse/JDK-8185734  
> - https://bugs.openjdk.org/browse/JDK-8267138 (fixed an oversight in 8185734)
> 
> See more details in my [PR description for 8185734](https://github.com/openjdk/jdk/pull/1757#issue-765285610), that's why this all sounded so familiar.
> 
> The mechanism in place since 8267138 should be enough for my understanding. @swesonga, can you find out why this is not sufficient in your case? Is this option not passed on to your test?
> 
>> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
> 
> In the libjvm code itself, we don't use C++ exceptions, and we catch all Windows SEH with `__try`/`__except`. We also don't want standard stack unwinding with these signals. So no need for `/EHxx`. My assumption is that the gtest framework itself uses C++ exceptions and therefore needs `/EHsc`. The documentation is not super clear on some aspects of this (https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model), but it says that for standard C++ exceptions to work `/EHsc` is needed.
> 
>> I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.
> 
> In my PR for 8184734, I wrote: 
> 
> " In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream."
> 
> So it looks this was the first thing I tried back then, and it failed.

> > How is it that we (Oracle) don't see these gtest death test failures in our CI? I'm guessing others (like SAP - @tstuefe ?) aren't either, since this issue is newly reported while the causing change was made more than 8 months ago.
> 
> Should gtests be enabled in the pre-checkin GitHub actions to prevent regressions? I think they take a few minutes to execute.

They are already executed :-) https://github.com/swesonga/jdk/actions/runs/16735029827/job/47374721173

They are launched from the GtestWrapper.java with the `--gtest_catch_exceptions=0` option. That's why it is so strange that this does not work for your case.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3166749667

From duke at openjdk.org  Fri Aug  8 08:24:15 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 08:24:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <4T5YaeiJd_xlg_vaHnee8S4jgAoXuZYvq8bCigtLIJk=.0838e9fd-3b8d-47f7-9e99-320917fcfa0e@github.com>
Message-ID: <RUPjvDVdVvDgQimeqcPqtpqlCdxw9Av4a5b93wcX4r0=.41c299b9-8ee0-432f-89b1-06b256313c9c@github.com>

On Fri, 8 Aug 2025 03:07:58 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   script. update
>
> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 73:
> 
>> 71:             paths.filter(Files::isRegularFile)
>> 72:                     .filter(path -> {
>> 73:                         String name = path.getFileName().toString();
> 
> IIUC this means that we count the number of cpp or hpp files that directly include a file, but should we count the number of cpp file that directly or transitively include a file instead?

That would be a much more sensitive number indeed. I'll look into the solution proposed below by @kimbarrett.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262278283

From duke at openjdk.org  Fri Aug  8 10:30:12 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 10:30:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <JqmB0VEJQOXUqDUyin1nAe7PmiaHHayrW73ZhjtyCY0=.14a5018c-04cf-4276-833a-2b0e2e34073a@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
 <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
 <JqmB0VEJQOXUqDUyin1nAe7PmiaHHayrW73ZhjtyCY0=.14a5018c-04cf-4276-833a-2b0e2e34073a@github.com>
Message-ID: <XFZFmRA7a3tmFMxncTD8qyDqrGlwf8fRPYDtrgNfcv4=.73afe13b-4176-4b30-8a9c-bbbac8ec3408@github.com>

On Fri, 8 Aug 2025 04:54:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > For example, when the threshold is set to 50 I get this compilation error:
> 
> How can we possibly get a compilation error when everything should build with PCH disabled?

Possibly some includes are inside namespaces or classes? I would have to check on this though.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3167372745

From duke at openjdk.org  Fri Aug  8 11:27:53 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 11:27:53 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v4]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <9F_mpCqxuTVGhOfdZn2M32xj7XEfOHlHg-m7yQB6c-A=.4ef5971f-fac0-442f-ac1e-ca3f6fefe922@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

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

  use .d files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/d6cd068b..5672a1b1

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

  Stats: 55 lines in 2 files changed: 16 ins; 18 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/26681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681

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

From duke at openjdk.org  Fri Aug  8 11:36:04 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 11:36:04 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v5]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <kz4UWZ9kaLLW3HtkaoM7m3InuzLL0jTgUOQoyPNqqSg=.c847bbe4-ba2b-480c-b6f8-ac76d126762b@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - nl
 - refresh. not needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/5672a1b1..5c8179d8

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

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

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

From duke at openjdk.org  Fri Aug  8 11:39:12 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 11:39:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
Message-ID: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>

On Fri, 8 Aug 2025 06:23:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   script. update
>
> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70:
> 
>> 68:         // Count inclusion times for each header
>> 69:         Map<String, Integer> occurrences = new HashMap<>();
>> 70:         try (Stream<Path> paths = Files.walk(hotspotPath)) {
> 
> I think walking the source tree is the wrong approach to gathering the data
> about include counts. I think better is to do a build and then look at the
> files <builddir>/hotspot/variant-server/libjvm/objs/*.d. From that one can build
> a completely accurate count of the transitive inclusions.

I followed this hint, the latest version of the script checks the `.d` files. 

Two observations:
- The magic number is now `2460` (more includes are taken into account, which makes sense)
- There is much less wiggle room, 2461 includes nothing, 2459 includes too much
- Runtime does not seem to be affected negatively or positively

If anybody is interested, this file contains the inclusion count for each source file: [inclusions_count.txt](https://github.com/user-attachments/files/21682561/inclusions_count.txt)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262707516

From kbarrett at openjdk.org  Fri Aug  8 12:45:13 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Aug 2025 12:45:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
Message-ID: <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>

On Fri, 8 Aug 2025 11:36:04 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70:
>> 
>>> 68:         // Count inclusion times for each header
>>> 69:         Map<String, Integer> occurrences = new HashMap<>();
>>> 70:         try (Stream<Path> paths = Files.walk(hotspotPath)) {
>> 
>> I think walking the source tree is the wrong approach to gathering the data
>> about include counts. I think better is to do a build and then look at the
>> files <builddir>/hotspot/variant-server/libjvm/objs/*.d. From that one can build
>> a completely accurate count of the transitive inclusions.
>
> I followed this hint, the latest version of the script checks the `.d` files. 
> 
> Two observations:
> - The magic number is now `2460` (more includes are taken into account, which makes sense)
> - There is much less wiggle room, 2461 includes nothing, 2459 includes too much
> - Runtime does not seem to be affected negatively or positively
> 
> If anybody is interested, this file contains the inclusion count for each source file: [inclusions_count.txt](https://github.com/user-attachments/files/21682561/inclusions_count.txt)

Something seems wrong with these numbers.

- There are 538 headers with include counts of 2460.
- There are only 1121 .o.cmdline files.

So how do we get include counts that are greater (by more than a factor of 2)
than the number of .d files?

Note that precompiled.hpp has an include count of 2456. There's 1 .d file that
depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded
from counting, although I guess it should just add one to every file.

Also, precompiled.hpp has an include count of 2456, so not the maximum count,
but close. Which is itself weird that it wouldn't be the most included file.
But it's hard to guess what might be going on with that until the surprising
high include count > number of .d files is understood.

That include count listing would also be more useful of sorted by count.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262874254

From asemenyuk at openjdk.org  Fri Aug  8 13:01:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 13:01:52 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>

> Rename "libwixhelper" in "libmsica".

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

  Rename libwixhelper dir

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26682/files
  - new: https://git.openjdk.org/jdk/pull/26682/files/358c24e6..60b30953

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

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

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

From asemenyuk at openjdk.org  Fri Aug  8 13:01:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 13:01:52 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <jiSxX8xgh2qzNWxSJFxgh7UOyEk3f3duIPdA2zC7tZE=.dbf880c5-23b3-448b-bb5b-5f8d71fc9afc@github.com>
 <zEzjSPPbjGEQBJJetvWWL0Q2-1C8YPF_yg2xNdkMZ0Q=.246e0a21-ad35-4e16-9c71-62bbbfc052bf@github.com>
 <-BIeyiFMGyJ7ENGH-11vvcurxCU6xidX0qa5QjeNgu8=.384c5cd9-7d84-47ed-970a-c459fe440fd4@github.com>
Message-ID: <z3TWLCzoXuNpQkZnPCaZW5SqQA6VWuaFoPG6d0dOwOM=.6c704418-369d-446a-b8e1-a0cbe0593300@github.com>

On Fri, 8 Aug 2025 01:03:58 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Without renaming the directory, I'm wondering how this could build at all.
>
> Good catch!

> Without renaming the directory, I'm wondering how this could build at all.

It did, but fortunately one windows test failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26682#discussion_r2262904670

From erikj at openjdk.org  Fri Aug  8 13:33:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 13:33:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v2]
In-Reply-To: <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <Bc_ZpN43x_dt_hqP4m9tjGs_EtmuUnOIUO0YGK8rlfQ=.b77601f6-1375-4dfa-9627-89ff50558853@github.com>
Message-ID: <zlHIYInt8Zb9LtJb8RCY0kTg5aCBHuVENoahJwWvBH0=.f2095a0e-4973-4682-84ed-740a1c7fe4bb@github.com>

On Thu, 7 Aug 2025 22:18:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   makefiles fixed

make/RunTests.gmk line 73:

> 71:   endif
> 72: endif
> 73: 

What happened here?

make/RunTests.gmk line 874:

> 872:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 873: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 874:     ))

You need to add the definitions of `LIBRARY_PREFIX` and `SHARED_LIBRARY_SUFFIX` for this to work in a remote testing situation.

I asked you to not use `{}` but `()` when referencing variables in makefiles.

There is no continuation indentation here, please adjust.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2262972522
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2262984228

From erikj at openjdk.org  Fri Aug  8 13:39:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 13:39:12 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
Message-ID: <ZVPIc6oMMeqfOsD9pOOq_e0UxqU87z8u4D-E4_3Aaos=.bf541b49-941c-4aba-be84-2625e40b8f7c@github.com>

On Fri, 8 Aug 2025 13:01:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename libwixhelper dir

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3100868948

From duke at openjdk.org  Fri Aug  8 14:10:15 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 14:10:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
Message-ID: <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>

On Fri, 8 Aug 2025 12:42:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Note that precompiled.hpp has an include count of 2456. There's 1 .d file that
depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded
from counting, although I guess it should just add one to every file.

Apparently `BUILD_LIBJVM.d` mentions all files multiple times:

% grep "utilities/waitBarrier.hpp" build/clang/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d | wc -l
1231


It's definitely reasonable to exclude it, I did it in the latest revision of the script.

Now, the numbers seem more reasonable:

% ls build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | wc -l
1232
% grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | \
            grep -v BUILD | sort | uniq | wc -l
1230
% grep "code/codeCache.hpp" inclusions_count.txt
code/codeCache.hpp=1230


Updated [inclusions_count.txt](https://github.com/user-attachments/files/21685761/inclusions_count.txt)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263090433

From duke at openjdk.org  Fri Aug  8 14:21:37 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 14:21:37 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v6]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <T4bVXVJ2AB7ydSo15DxXjEEm35EaT4UwocLKLv9CMv8=.fff90a09-7d9c-4980-be6c-385c4e9dea3d@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

Francesco Andreuzzi has updated the pull request incrementally with five additional commits since the last revision:

 - refresh
 - refresh
 - exclude precompiled
 - nn
 - exclude BUILD, cpp, compiler specific

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/5c8179d8..dba3a6aa

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

  Stats: 45 lines in 2 files changed: 28 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681

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

From duke at openjdk.org  Fri Aug  8 14:36:00 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 14:36:00 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v7]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <nttNeX1ucR-4KpAB4E73taCMqN8__OrRoamFba-j0zA=.a910a659-0214-4762-87ca-626159e9eeb3@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

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

  refresh

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/dba3a6aa..3546dd18

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

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

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

From duke at openjdk.org  Fri Aug  8 14:50:01 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 14:50:01 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - two times might be too much
 - ops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/3546dd18..71950aed

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

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

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

From qamai at openjdk.org  Fri Aug  8 15:05:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 15:05:14 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
 <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
Message-ID: <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>

On Fri, 8 Aug 2025 14:08:02 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Something seems wrong with these numbers.
>> 
>> - There are 538 headers with include counts of 2460.
>> - There are only 1121 .o.cmdline files.
>> 
>> So how do we get include counts that are greater (by more than a factor of 2)
>> than the number of .d files?
>> 
>> Note that precompiled.hpp has an include count of 2456. There's 1 .d file that
>> depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded
>> from counting, although I guess it should just add one to every file.
>> 
>> Also, precompiled.hpp has an include count of 2456, so not the maximum count,
>> but close. Which is itself weird that it wouldn't be the most included file.
>> But it's hard to guess what might be going on with that until the surprising
>> high include count > number of .d files is understood.
>> 
>> That include count listing would also be more useful of sorted by count.
>
>> Note that precompiled.hpp has an include count of 2456. There's 1 .d file that
> depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded
> from counting, although I guess it should just add one to every file.
> 
> Apparently `BUILD_LIBJVM.d` mentions all files multiple times:
> 
> % grep "utilities/waitBarrier.hpp" build/clang/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.d | wc -l
> 1231
> 
> 
> It's definitely reasonable to exclude it, I did it in the latest revision of the script.
> 
> Now, the numbers seem more reasonable:
> 
> % ls build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | wc -l
> 1232
> 
> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | \
>             grep -v BUILD | sort | uniq | wc -l
> 1230
> 
> % grep "code/codeCache.hpp" inclusions_count.txt
> code/codeCache.hpp=1230
> 
> 
> Updated [inclusions_count.txt](https://github.com/user-attachments/files/21685761/inclusions_count.txt)

I assume this means that other `.d` files might include a header multiple times, too. Is it reasonable to count only the number of files containing a header instead of number of appearances?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263225465

From rriggs at openjdk.org  Fri Aug  8 15:07:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 15:07:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
Message-ID: <tTtYOfGIYxI6b1zdtvFiD60sX1hxyfse8vL3omdTLE8=.7a4766ba-180a-44f1-a382-efa2ab8d345c@github.com>

On Fri, 8 Aug 2025 05:25:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - merge
>  - fix comments about closeDescriptors
>  - Feedback Roger
>  - tolerate sigaction failing
>  - Fixes
>  - fix
>  - start+repro-case

Looks good, Thanks.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3101175850

From duke at openjdk.org  Fri Aug  8 15:20:15 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 15:20:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
 <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
 <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>
Message-ID: <aEK5CpEg5tyRhTu59oouB4xS8MmRGXxJOe8c6Iyaltc=.4649e2b6-99d2-4c93-8f9c-4a8564cfc7f9@github.com>

On Fri, 8 Aug 2025 15:02:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I assume this means that other .d files might include a header multiple times, too.

>From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something?


% grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l
1230

% grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l
1230


I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263257970

From stuefe at openjdk.org  Fri Aug  8 15:25:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Aug 2025 15:25:15 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v3]
In-Reply-To: <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <EY0dwLGJI7cf57oZXVKth4sxWqvfcn_uEShsRPzjFwg=.2967e808-dad5-4257-a24d-1271dd35980f@github.com>
 <FYMkOSCTDj16aIWW4JXKxr_7j5_UJsmTQW2ERfrvGHE=.672de8f5-9abb-4286-85aa-00966a8578d7@github.com>
Message-ID: <3qqEGFbrUy-TCwnzUT1vPGmbCS8zuIL5iZAn-ylmKeg=.8b43f058-920b-4064-8897-3bad11bbe23c@github.com>

On Thu, 7 Aug 2025 14:17:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comments about closeDescriptors
>
> It looks like I created a merge conflict by asking to fix these.  
> Another PR https://git.openjdk.org/jdk/pull/26667 is also changing them. (At the time the other PR had not started).
> The least chaos may be created by backing out those changes from this PR.  (Unless you like your words better than PR#26667).

Thanks @RogerRiggs and @erikj79 !

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3168292525

From qamai at openjdk.org  Fri Aug  8 15:27:13 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 15:27:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <aEK5CpEg5tyRhTu59oouB4xS8MmRGXxJOe8c6Iyaltc=.4649e2b6-99d2-4c93-8f9c-4a8564cfc7f9@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
 <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
 <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>
 <aEK5CpEg5tyRhTu59oouB4xS8MmRGXxJOe8c6Iyaltc=.4649e2b6-99d2-4c93-8f9c-4a8564cfc7f9@github.com>
Message-ID: <VabF2v0dEPzu-8PqnAPTDlp_81rVAt5upfz6LxN8x00=.d94c90ca-6691-4902-9ac6-0f7d9f1b18a9@github.com>

On Fri, 8 Aug 2025 15:17:06 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> I assume this means that other `.d` files might include a header multiple times, too. Is it reasonable to count only the number of files containing a header instead of number of appearances?
>
>> I assume this means that other .d files might include a header multiple times, too.
> 
> From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something?
> 
> 
> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l
> 1230
> 
> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l
> 1230
> 
> 
> I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file.

Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263272948

From rriggs at openjdk.org  Fri Aug  8 15:30:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Aug 2025 15:30:17 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <gRqOTSGg7cHFNKd3Z-MacgeE52i09SZ7L3G28NyPSDY=.df63d950-f2f6-453f-b098-c0513750b298@github.com>
Message-ID: <jl0Mu2cqAqBMQyp8pLNMSnvFUIrW_xawO7eggnWG_T8=.dc29c76e-1d40-4e94-8388-8b3513c5144a@github.com>

On Wed, 6 Aug 2025 12:22:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - merge
>>  - fix comments about closeDescriptors
>>  - Feedback Roger
>>  - tolerate sigaction failing
>>  - Fixes
>>  - fix
>>  - start+repro-case
>
> Build changes look trivially good.

@erikj79 Please re-review; Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26615#issuecomment-3168308584

From qamai at openjdk.org  Fri Aug  8 15:35:15 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 15:35:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
Message-ID: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com>

On Fri, 8 Aug 2025 06:30:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   script. update
>
> src/hotspot/share/precompiled/precompiled.hpp line 29:
> 
>> 27: 
>> 28: // These header files are included in at least 130 C++ files, as of
>> 29: // measurements made in August 2025.
> 
> I don't think there's anything particularly special about the number 130.
> 
> Another thing to consider when a header file has a high include count is
> whether it's being overincluded. We've had lots of those, and some folks
> occasionally try to poke at that problem. Some of the removals here look like
> they might be a result of such efforts.
> 
> Still another thing to consider is the cost of inclusion. Some files may just
> be a lot more expensive to process and benefit more for being precompiled.
> File size can be an indicator, but there are others. Unfortunately, I don't
> know of a good way to measure this.

You need to modify the comment here, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263274537

From duke at openjdk.org  Fri Aug  8 15:35:16 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 15:35:16 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com>
Message-ID: <sYbzksOVK3cZkIRuY6I0Yg_AwMoLhILrjrzSv18NNCA=.5e934d5f-99c6-479f-8f6d-b7f506fed531@github.com>

On Fri, 8 Aug 2025 15:25:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/precompiled/precompiled.hpp line 29:
>> 
>>> 27: 
>>> 28: // These header files are included in at least 130 C++ files, as of
>>> 29: // measurements made in August 2025.
>> 
>> I don't think there's anything particularly special about the number 130.
>> 
>> Another thing to consider when a header file has a high include count is
>> whether it's being overincluded. We've had lots of those, and some folks
>> occasionally try to poke at that problem. Some of the removals here look like
>> they might be a result of such efforts.
>> 
>> Still another thing to consider is the cost of inclusion. Some files may just
>> be a lot more expensive to process and benefit more for being precompiled.
>> File size can be an indicator, but there are others. Unfortunately, I don't
>> know of a good way to measure this.
>
> You need to modify the comment here, too.

Right, I'll wait just a bit so the discussion on how to approach the problem stabilizes :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263289968

From qamai at openjdk.org  Fri Aug  8 15:35:13 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 15:35:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
Message-ID: <F4FDII9lmEQ1X4slMuOo5iYth1m-KtiqARW0iG7PMl0=.f6d22be3-1f54-4d03-9a4d-255b75a97593@github.com>

On Fri, 8 Aug 2025 14:50:01 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - two times might be too much
>  - ops

Marked as reviewed by qamai (Committer).

src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85:

> 83:                         try {
> 84:                             // The first line contains the object name
> 85:                             return Files.lines(file).skip(1);

Or maybe `return Files.lines(file).skip(1).distinct()`?

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

PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3101235921
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263282801

From duke at openjdk.org  Fri Aug  8 15:35:17 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 15:35:17 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <F4FDII9lmEQ1X4slMuOo5iYth1m-KtiqARW0iG7PMl0=.f6d22be3-1f54-4d03-9a4d-255b75a97593@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
 <F4FDII9lmEQ1X4slMuOo5iYth1m-KtiqARW0iG7PMl0=.f6d22be3-1f54-4d03-9a4d-255b75a97593@github.com>
Message-ID: <gcTDBY6yR5Kwm9dq4rMq7EfCLply4MgLHcT-gYDcBAY=.ca59c3d2-2cc7-4d2b-aca4-9f96b301d268@github.com>

On Fri, 8 Aug 2025 15:28:41 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - two times might be too much
>>  - ops
>
> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85:
> 
>> 83:                         try {
>> 84:                             // The first line contains the object name
>> 85:                             return Files.lines(file).skip(1);
> 
> Or maybe `return Files.lines(file).skip(1).distinct()`?

`distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263292750

From qamai at openjdk.org  Fri Aug  8 16:31:15 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Aug 2025 16:31:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <gcTDBY6yR5Kwm9dq4rMq7EfCLply4MgLHcT-gYDcBAY=.ca59c3d2-2cc7-4d2b-aca4-9f96b301d268@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
 <F4FDII9lmEQ1X4slMuOo5iYth1m-KtiqARW0iG7PMl0=.f6d22be3-1f54-4d03-9a4d-255b75a97593@github.com>
 <gcTDBY6yR5Kwm9dq4rMq7EfCLply4MgLHcT-gYDcBAY=.ca59c3d2-2cc7-4d2b-aca4-9f96b301d268@github.com>
Message-ID: <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com>

On Fri, 8 Aug 2025 15:32:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 85:
>> 
>>> 83:                         try {
>>> 84:                             // The first line contains the object name
>>> 85:                             return Files.lines(file).skip(1);
>> 
>> Or maybe `return Files.lines(file).skip(1).distinct()`?
>
> `distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file?

It's not like stream is the most performant method to do anything anyway. I think the clarification is worth the additional overhead, especially when this file is not run very frequently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263469891

From erikj at openjdk.org  Fri Aug  8 16:45:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 16:45:14 GMT
Subject: RFR: 8364611: (process) Child process SIGPIPE signal disposition
 should be default [v4]
In-Reply-To: <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
 <6NEPqrey2YlmtxSW1WWUVw2rOlmOCr2X28wBJUmkOkk=.0d5e8c3e-479e-457d-a145-cb9b09133553@github.com>
Message-ID: <sFOmhm5igHPr1NEe0LNX5PyoALGswpKczW-Fb55Pz6w=.4bd8da8a-f834-4893-b440-abc8f743aea5@github.com>

On Fri, 8 Aug 2025 05:25:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
>> 
>> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
>> 
>> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
>> 
>> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - merge
>  - fix comments about closeDescriptors
>  - Feedback Roger
>  - tolerate sigaction failing
>  - Fixes
>  - fix
>  - start+repro-case

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26615#pullrequestreview-3101549262

From erikj at openjdk.org  Fri Aug  8 17:34:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 17:34:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
Message-ID: <hMBqjBQtHIrTQ7f6WyYVTyzYyQSgl_AU6f5MYCBGdUY=.adda9dd1-c6c7-4a8b-8e5c-61dcc947873b@github.com>

On Fri, 8 Aug 2025 14:50:01 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - two times might be too much
>  - ops

The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3168810638

From dcubed at openjdk.org  Fri Aug  8 18:58:12 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 8 Aug 2025 18:58:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <VabF2v0dEPzu-8PqnAPTDlp_81rVAt5upfz6LxN8x00=.d94c90ca-6691-4902-9ac6-0f7d9f1b18a9@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
 <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
 <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>
 <aEK5CpEg5tyRhTu59oouB4xS8MmRGXxJOe8c6Iyaltc=.4649e2b6-99d2-4c93-8f9c-4a8564cfc7f9@github.com>
 <VabF2v0dEPzu-8PqnAPTDlp_81rVAt5upfz6LxN8x00=.d94c90ca-6691-4902-9ac6-0f7d9f1b18a9@github.com>
Message-ID: <KY3E19_8Amz9yBKtKcxQ0AqX-68Uw5QxOM1FN7C1Vl8=.649ba597-52c7-4f38-b869-1caefec7e7a1@github.com>

On Fri, 8 Aug 2025 15:24:46 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> I assume this means that other .d files might include a header multiple times, too.
>> 
>> From the following two numbers, I deduce `code/codeCache.hpp` is (transitively) included in 1230 files, with each inclusion coming from a unique `.d` file. Am I missing something?
>> 
>> 
>> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | wc -l
>> 1230
>> 
>> % grep "code/codeCache.hpp" build/clang/hotspot/variant-server/libjvm/objs/*.d | grep -v BUILD | sort | uniq | wc -l
>> 1230
>> 
>> 
>> I haven't checked every single file, but I'd expect each include to appear at most once in each `.d` file.
>
> Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great.

I suspect that the multiple includes reported in the .d files are accurate. The .d file appears
to report the number of times we `#include` a file, however, because if the include-guard
constructs we use, the content is pulled in only once.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2263788850

From almatvee at openjdk.org  Fri Aug  8 21:01:17 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 8 Aug 2025 21:01:17 GMT
Subject: RFR: 8364129: Rename libwixhelper [v2]
In-Reply-To: <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
 <FlkzCAW2nhs9hAnxLwf82BU39UnTR_P4buWfjbqDRnM=.61564841-7673-43b3-8b3c-356a160a88c4@github.com>
Message-ID: <7x2El6yrGCX6moklfttc-g1-yfTriCod1RM1DrrXt6k=.4e1325b8-ed13-4b2a-b086-e8afb3081f5c@github.com>

On Fri, 8 Aug 2025 13:01:52 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Rename "libwixhelper" in "libmsica".
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename libwixhelper dir

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26682#pullrequestreview-3102135060

From duke at openjdk.org  Fri Aug  8 21:43:23 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 21:43:23 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v9]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <fZ3xDyqDXDJJYUAMZgHwGv3j0YvBFFx4Z0aq7sg9P08=.a6d17ace-d41d-4b2b-9495-ff560f248198@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

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

  distinct

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/71950aed..3116b39c

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

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

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

From duke at openjdk.org  Fri Aug  8 21:43:24 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 21:43:24 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
 <F4FDII9lmEQ1X4slMuOo5iYth1m-KtiqARW0iG7PMl0=.f6d22be3-1f54-4d03-9a4d-255b75a97593@github.com>
 <gcTDBY6yR5Kwm9dq4rMq7EfCLply4MgLHcT-gYDcBAY=.ca59c3d2-2cc7-4d2b-aca4-9f96b301d268@github.com>
 <57LBOn04BwPwiJdf_UUqgud4h9qhj38ga2bT56akoIc=.6dcf1641-1d82-46a6-b157-1fb7a33b2342@github.com>
Message-ID: <yZegOL3at6VANhleohH5ElPgqBtVO58-HSIDlEt9-Kw=.f892695c-caec-4253-9b4f-f51b4df5cba9@github.com>

On Fri, 8 Aug 2025 16:28:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `distinct()` has some overhead, do we need it? Do we expect duplicate headers in a file?
>
> It's not like stream is the most performant method to do anything anyway. I think the clarification is worth the additional overhead, especially when this file is not run very frequently.

3116b39c5dc812c1bfb0994bda3a82c9f66870af

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2264028292

From asemenyuk at openjdk.org  Fri Aug  8 21:45:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Aug 2025 21:45:15 GMT
Subject: Integrated: 8364129: Rename libwixhelper
In-Reply-To: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
References: <DJ_R1wmnnD8Cqq5dh76i_um9eRQTbFDSo-IZN727pxg=.cbc8c725-7fe4-4ece-91cc-467f810bc8a4@github.com>
Message-ID: <Ru5SqHXDuHm_VELNoIEdW3dOvAhZrHK1y9Vbn3-vL9Q=.8b6f6501-4a8b-4846-afcf-963b24d828b3@github.com>

On Thu, 7 Aug 2025 18:38:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rename "libwixhelper" in "libmsica".

This pull request has now been integrated.

Changeset: c1c01556
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1c0155604cbb6c42a220d391a88b029776bdb95
Stats:     11 lines in 7 files changed: 0 ins; 0 del; 11 mod

8364129: Rename libwixhelper

Reviewed-by: erikj, almatvee

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

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

From duke at openjdk.org  Fri Aug  8 22:11:32 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 22:11:32 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - magic number: 400
 - inline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/3116b39c..be25d341

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

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

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

From duke at openjdk.org  Fri Aug  8 22:17:12 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 8 Aug 2025 22:17:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v8]
In-Reply-To: <hMBqjBQtHIrTQ7f6WyYVTyzYyQSgl_AU6f5MYCBGdUY=.adda9dd1-c6c7-4a8b-8e5c-61dcc947873b@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <sUzkkcpUcq7zc-cWlI3PA1wIWoTXqI7mQA5oVYS1k3A=.4c27529e-d9ed-4c66-a505-e0a8563509fe@github.com>
 <hMBqjBQtHIrTQ7f6WyYVTyzYyQSgl_AU6f5MYCBGdUY=.adda9dd1-c6c7-4a8b-8e5c-61dcc947873b@github.com>
Message-ID: <nRp9eoz0OIkqLpojkvuXf6ihp_vnCLX_uTNxvRnLzQY=.125d757c-a09a-4693-a4fc-a6451747e55f@github.com>

On Fri, 8 Aug 2025 17:31:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features.

The last commit (be25d3413b432b56e9789eae55920f1862008911) should fix the problem. I made a build with the following configuration:

./configure \
        --with-toolchain-type=clang \
        --disable-jvm-feature-shenandoahgc \
        --disable-jvm-feature-zero \
        --disable-jvm-feature-zgc \
        --disable-jvm-feature-g1gc \
        --disable-jvm-feature-parallelgc \
        --disable-jvm-feature-epsilongc

and then I ran the script on this build to extract the [inclusions count](https://github.com/user-attachments/files/21692915/inclusions_count.txt). This could be included in the README file attached to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3169427612

From lmesnik at openjdk.org  Sun Aug 10 06:09:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 10 Aug 2025 06:09:00 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  fixed makefiles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/6d505a8b..49c2a67d

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

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

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

From kbarrett at openjdk.org  Mon Aug 11 01:23:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 11 Aug 2025 01:23:18 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <KY3E19_8Amz9yBKtKcxQ0AqX-68Uw5QxOM1FN7C1Vl8=.649ba597-52c7-4f38-b869-1caefec7e7a1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <4hk98YWMw1Mf2CTBe2Yb0ZvGXDqoDl2MqMwKvfXbzPM=.09065989-dd8f-4bdc-a2f9-83b13d658173@github.com>
 <50Lh-a6pTujiDCyHwPIcC5zzgiu-zP-pAiQeyu4CJcs=.e74b0e74-b87f-45d4-b441-f2d3045fd101@github.com>
 <5kr1ZhhyDjDuI87uSmB-Xh0rzIHq2tgnVTZXWNdHqGs=.e33307ca-794d-4419-a2b5-7ec2f6dd4c95@github.com>
 <ogsVh7HDvbQS84NzXY58YpuPQKxSt8jwHCGnPryH_lQ=.fbd681ca-758c-4c76-b620-b9bd77cfd679@github.com>
 <aEK5CpEg5tyRhTu59oouB4xS8MmRGXxJOe8c6Iyaltc=.4649e2b6-99d2-4c93-8f9c-4a8564cfc7f9@github.com>
 <VabF2v0dEPzu-8PqnAPTDlp_81rVAt5upfz6LxN8x00=.d94c90ca-6691-4902-9ac6-0f7d9f1b18a9@github.com>
 <KY3E19_8Amz9yBKtKcxQ0AqX-68Uw5QxOM1FN7C1Vl8=.649ba597-52c7-4f38-b869-1caefec7e7a1@github.com>
Message-ID: <LYCx8wUlz99MIGztkceKzmNS02F7MaKid7NBFWTyQI0=.92af3bbe-6eb3-4e22-a96c-1602d6925f0b@github.com>

On Fri, 8 Aug 2025 18:55:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thanks for the clarification, I think that it is fine, then, although a comment explaining in the code would be great.
>
> I suspect that the multiple includes reported in the .d files are accurate. The .d file appears
> to report the number of times we `#include` a file, however, because if the include-guard
> constructs we use, the content is pulled in only once.

The number of times a header is (directly or indirectly) included by a given
source file doesn't affect the number of times that header appears in the .d
file associated with that source file. The compiler uniquifies that set
(though links might confuse things, but that's not an issue here).

The .d files consist of a set of targets, and for each target, the set of
dependencies.

For the <sourcefile>.d files, there's one target, <sourcefile>.o, with its
dependencies (once each).

For BUILD_LIBJVM.d, there's a target for each .o file. And for each of those
targets, it's dependencies (once each). Essentially BUILD_LIBJVM.d includes a
concatenation of all the <sourcefile>.d files. And since there are duplicates
among the dependencies of different targets, there are many(!) duplicates in
this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265529851

From kbarrett at openjdk.org  Mon Aug 11 01:49:20 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 11 Aug 2025 01:49:20 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

> > The latest version fails for me. I'm guessing because we exclude shenandoah by default for OracleJDK builds so having those headers in precompiled.hpp messes things up. I think we need to be careful with headers that are part of optional features.
> 
> The last commit ([be25d34](https://github.com/openjdk/jdk/commit/be25d3413b432b56e9789eae55920f1862008911)) should fix the problem. I made a build with the following configuration:
> 
> ```
> ./configure \
>         --with-toolchain-type=clang \
>         --disable-jvm-feature-shenandoahgc \
>         --disable-jvm-feature-zero \
>         --disable-jvm-feature-zgc \
>         --disable-jvm-feature-g1gc \
>         --disable-jvm-feature-parallelgc \
>         --disable-jvm-feature-epsilongc
> ```
> 
> and then I ran the script on this build to extract the [inclusions count](https://github.com/user-attachments/files/21692915/inclusions_count.txt). This could be included in the README file attached to this PR.

Other optional features include cds, c1, jfr, and jvmci, so files from those
directories also ought to be excluded.

The (current) list of optional features is here:
https://github.com/openjdk/jdk/blame/022e29a77533aacabd56820d00ecffa9646a8362/make/autoconf/jvm-features.m4#L47-L49

    cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check \
    jvmci jvmti link-time-opt management minimal opt-size parallelgc \
    serialgc services shenandoahgc vm-structs zero zgc \

Not all of these have their own directories.  Even where they do, the feature
name and directory name aren't always the same. (The compiler1 feature and the
c1 directory being an obvious example.)

I didn't spot any files for other optional features in the latest list, other
than the ones called out in the first sentence of this comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173072518

From dholmes at openjdk.org  Mon Aug 11 06:29:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Aug 2025 06:29:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>
Message-ID: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com>

On Mon, 11 Aug 2025 01:46:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Other optional features include cds, c1, jfr, and jvmci, so files from those directories also ought to be excluded.

Can't these just be conditionalized with an INCLUDE_xxx check instead of being excluded?

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173410334

From ihse at openjdk.org  Mon Aug 11 08:02:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:02:20 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <-U8KN5uNIUhrTn2MCESloqat2y6ZFvgxK-bsmqIDFFI=.ab50a73b-80bd-49ec-aac9-b633cc92b915@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

There is a handy shortcut for creating a build with all optional features disabled, `--with-jvm-variants=custom`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173648190

From kbarrett at openjdk.org  Mon Aug 11 08:02:20 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 11 Aug 2025 08:02:20 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>
 <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com>
Message-ID: <YvGZ5TDuVoTVxTVdOSvsLHITISXybzzErXrb8_qxVoE=.8681daec-241e-47de-b041-d0cd4c8cb6d7@github.com>

On Mon, 11 Aug 2025 06:26:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Other optional features include cds, c1, jfr, and jvmci, so files from those directories also ought to be excluded.
> 
> Can't these just be conditionalized with an INCLUDE_xxx check instead of being excluded?

Yeah, that might be better than excluding altogether. But still need to figure out which files to (conditionally) exclude.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173654009

From ihse at openjdk.org  Mon Aug 11 08:02:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:02:21 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
Message-ID: <RTlOPgwfg8N_IX9I6GKaCJgaxsFl4hxcUmnz3g_SslY=.700807c0-5827-46a2-a6f6-821a44c025e6@github.com>

On Fri, 8 Aug 2025 06:32:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - magic number: 400
>>  - inline
>
> src/hotspot/share/precompiled/precompiled.hpp line 70:
> 
>> 68: #include "utilities/ticks.hpp"
>> 69: 
>> 70: #ifdef TARGET_COMPILER_visCPP
> 
> All of the reported testing was on Linux. These were included specifically because measurements
> said their inclusion here was beneficial. And my recollection from previous discussions is that
> Visual Studio may be the compiler where precompiled headers are most beneficial.

Indeed, Visual Studio is the place where PCH is most needed. I see Erik says he tested on Windows with no difference. While he concluded that this means no regression, I see it as a missed opportunity. Giving the Windows platform a bit of extra love can probably increase compilation speed where it is needed the most.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265948776

From ihse at openjdk.org  Mon Aug 11 08:09:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:09:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
 <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
Message-ID: <AfzAvpDoUvaJuHA5oo7gnslsgbSeLfyFkaSblJzmdl0=.ad2b59cf-1bf5-473d-8d68-fdcfbf541035@github.com>

On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> Also, maybe check in the generation script as well? I think a subfolder here would be fine: https://github.com/openjdk/jdk/tree/master/src/utils.

@shipilev I'm not sure this is a proper place. The other tools in `src/utils` are stand-alone utilities that could be useful to end users, like hsdis and IdealGraphVisualizer. In contrast, tools that are useful for developers are put either into `bin` or `make/scripts`. Normally, I think `bin` is what would make most sense, and the latter is mostly a legacy result of people using `make` as a `misc` back in the bad old hg-forest days, but in this particular case I think it might be the best placement. This is after all clearly about optimizing the build speed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173680429

From ihse at openjdk.org  Mon Aug 11 08:13:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:13:12 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <YvGZ5TDuVoTVxTVdOSvsLHITISXybzzErXrb8_qxVoE=.8681daec-241e-47de-b041-d0cd4c8cb6d7@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>
 <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com>
 <YvGZ5TDuVoTVxTVdOSvsLHITISXybzzErXrb8_qxVoE=.8681daec-241e-47de-b041-d0cd4c8cb6d7@github.com>
Message-ID: <ujg3ARcP9BJJNX6YvAF6zXcjMopcObCADyJGSu0u4mk=.fb4a5456-bdc9-4d52-9426-af3374241a02@github.com>

On Mon, 11 Aug 2025 07:59:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> But still need to figure out which files to (conditionally) exclude.

Maybe first make a baseline build with no optional features, and analyze the result with this tool. And then enable each individual feature, re-build and re-analyze, and see how it differs. If a file then makes it to the PCH list, it is useful when enabling that feature, and it is potentially only correct to include with that feature enabled, so it could be added with an include guard.

That will require a bit more manual work (unless this process too can be automated), but it will probably give the best results.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173692668

From ihse at openjdk.org  Mon Aug 11 08:21:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:21:22 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v3]
In-Reply-To: <sYbzksOVK3cZkIRuY6I0Yg_AwMoLhILrjrzSv18NNCA=.5e934d5f-99c6-479f-8f6d-b7f506fed531@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <NdlNE_ObVOECvufaEfZQq7LtOitSDeJjkDi-GHLB3lM=.7bbda2e0-49d1-44ff-a4fd-fa394c92ab6e@github.com>
 <Tw_bUkgrRZ9amdgL2LAmhzj3CMvy5jOoXhTeRmPMmFA=.610bde47-2acb-4ae6-9557-ccd38c866225@github.com>
 <7fGzfcVu-qJat5d53jOHN6hJmLKT26IKA_Q6Z9LySVc=.8225de02-89b8-4523-9aaf-9a402a2d7730@github.com>
 <sYbzksOVK3cZkIRuY6I0Yg_AwMoLhILrjrzSv18NNCA=.5e934d5f-99c6-479f-8f6d-b7f506fed531@github.com>
Message-ID: <k1O-EJWUfoDy28tJMcM14e8VUzbCuImnjXfAa2LVijE=.b17bcd55-9006-4fbc-a607-ade0c9a80738@github.com>

On Fri, 8 Aug 2025 15:31:18 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> You need to modify the comment here, too.
>
> Right, I'll wait just a bit so the discussion on how to approach the problem stabilizes :)

This number is based on my original experimentation. If I tried to lower the bar by lowering the number, the PCH list grew too much and it made for a worse performance. And contrary, if I raised the number, fewer files where included which made the PCH quicker to process but less helpful. That number was the optimum I found. It seems from https://bugs.openjdk.org/browse/JDK-8365053 that this is still around the optimum. However, rather than just mentioning the number in the comment, the rationale could be specified, like `the optimum number of includes`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2265991618

From ihse at openjdk.org  Mon Aug 11 08:41:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 08:41:12 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <0fo80CHLoG2GkcIxyxaLmKF0Zy2SbbYf11d_An86FIQ=.2fd29302-0890-4aaa-bd8f-94c585ad5b95@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
> 
> That decision seems pretty old, like maybe from the initial introduction of gtest. I haven't tracked down why, or whether the reasons are still valid. I think it would be better to change that, assuming that's possible.

Your assumption is correct. This is from the initial JDK-8148244. I don't know if there is any rationale, or if this was just added by following gtest documentation.

I guess it can be removed. I'm starting a test run of hs-tier1 without it right now, but I'm not sure if that is enough to provoke any potential problems.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3173771307

From duke at openjdk.org  Mon Aug 11 08:59:16 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 08:59:16 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <ujg3ARcP9BJJNX6YvAF6zXcjMopcObCADyJGSu0u4mk=.fb4a5456-bdc9-4d52-9426-af3374241a02@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <RDYa1tX8fWCHl6ztCmHzSpCfIVtcfijdqL2WFIkIskI=.59e3591f-623b-41ec-9c54-3f82258888a3@github.com>
 <-jY8BYznUPdJuRtoV-JSSDwa96qtMRN3BqOlms5Mkuk=.83b456e1-074b-462f-b621-9a2ea57495ad@github.com>
 <YvGZ5TDuVoTVxTVdOSvsLHITISXybzzErXrb8_qxVoE=.8681daec-241e-47de-b041-d0cd4c8cb6d7@github.com>
 <ujg3ARcP9BJJNX6YvAF6zXcjMopcObCADyJGSu0u4mk=.fb4a5456-bdc9-4d52-9426-af3374241a02@github.com>
Message-ID: <0DhdCTNjwi_HGzvp9ybEEikGSHvqSvWTBP4PIIbdzEI=.7bbfa37f-be55-4925-9cc9-40850ba1f54c@github.com>

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

> > But still need to figure out which files to (conditionally) exclude.
> 
> Maybe first make a baseline build with no optional features, and analyze the result with this tool. And then enable each individual feature, re-build and re-analyze, and see how it differs. If a file then makes it to the PCH list, it is useful when enabling that feature, and it is potentially only correct to include with that feature enabled, so it could be added with an include guard.
> 
> That will require a bit more manual work (unless this process too can be automated), but it will probably give the best results.

Hi @magicus, thanks for the hint. I'll give it a shot and post the results here!

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3173824367

From ihse at openjdk.org  Mon Aug 11 09:00:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:00:11 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <2fhrymDxQIwpibGo5SC_-Y_4VxXC5Omsnj_GAbETK3A=.26b513c0-1c1f-460e-99e5-33d6548fdc83@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

Well that did not work:

 warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
 ```
when compiling `googletest-1.14.0/googlemock/src/gmock-spec-builders.cc`.

I'm not sure really of the effect of including, or not including, `/EHsc` when building gtest. An alternative is to disable C4530; I can try that as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3173825277

From ihse at openjdk.org  Mon Aug 11 09:22:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:22:17 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <JHtigp6K2FNIdF1cOwhOI7rWdYzIf-1djjiHDBxzAkY=.f7c95c26-ec49-4683-8967-b59281c0c8a3@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

make/modules/jdk.compiler/Gensrc.gmk line 82:

> 80: ################################################################################
> 81: #
> 82: # Generate FlagsEnum from Flags constants:

Suggestion:

# Generate FlagsEnum from Flags constants

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2266118863

From ihse at openjdk.org  Mon Aug 11 09:30:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:30:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

make/RunTests.gmk line 882:

> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
> 882:     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:${TEST_IMAGE_DIR}/hotspot/jtreg/native/$${AGENT}'

Suggestion:

    $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:$(TEST_IMAGE_DIR)/hotspot/jtreg/native/$$(AGENT)'

make/RunTests.gmk line 885:

> 883:     $1_JTREG_BASIC_OPTIONS += $$(addprefix $$(JTREG_PROBLEM_LIST_PREFIX), $$(wildcard \
> 884: 	$$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
> 885:     ))

Suggestion:

	    $$(addprefix $$($1_TEST_ROOT)/, ProblemList-jvmti-stress-agent.txt) \
        ))


Also, the comment on line length applies here.

test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp line 38:

> 36:  * Test supports 2 modes:
> 37:  *   - standard, where the agent doesn't require debugging capabilities
> 38:  *   - debug, where the agent  additionally test debug-related functionality

Suggestion:

 *   - debug, where the agent additionally test debug-related functionality

test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp line 40:

> 38:  *   - debug, where the agent  additionally test debug-related functionality
> 39:  *   The debug mode is incompatible with debugger tests and debug jvmti tests.
> 40:  *   The standard mode should be compatible with all tests except probelmlisted.

Suggestion:

 *   The standard mode should be compatible with all tests except problemlisted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266130714
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266133869
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266137865
PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266138425

From ihse at openjdk.org  Mon Aug 11 09:30:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:30:17 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <KQRRnWEp_65HO7lDY2KTW3FopxsZ2iGKHrFZqzFLamo=.164014c6-ce13-4d57-873f-742df4cc7d96@github.com>
Message-ID: <FW4kGj0stWUxMeTQHwNYex2jDHcyjNiYD9IjzSvxHec=.41d1c18c-3909-46b6-8392-05603cf940e9@github.com>

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

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed makefiles
>
> make/RunTests.gmk line 882:
> 
>> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
>> 882:     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:${TEST_IMAGE_DIR}/hotspot/jtreg/native/$${AGENT}'
> 
> Suggestion:
> 
>     $1_JTREG_BASIC_OPTIONS += -javaoption:'-agentpath:$(TEST_IMAGE_DIR)/hotspot/jtreg/native/$$(AGENT)'

Also, this line looks quite long. Can you check that it does not pass 80 characters? (Can't tell on github reviews...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266132846

From ihse at openjdk.org  Mon Aug 11 09:38:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:38:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

make/RunTests.gmk line 881:

> 879: 
> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)

I don't understand the usage scenario here. Are you supposed to run this like `make test JTREG=JVMTI_STRESS_AGENT=true`? If so, this will result in `-javaoption:'-agentpath:<test-image>/hotspot/jtreg/native/libJvmtiStressAgent.so=true` being sent to jtreg, and that looks sus. 

Or how should this be used? 

In fact, this option should be described in testing.md.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2266155034

From ihse at openjdk.org  Mon Aug 11 09:39:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:39:21 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <gk7J2fluyshhY0YHFZDnWaXMOdnMtH42y1z7FGthfwU=.498019c5-643c-46fb-b744-c3c0bb1b8140@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3104868381

From jlahoda at openjdk.org  Mon Aug 11 09:43:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:43:36 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v4]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <2N2f71azV7x8Cn2gSeFUrOkNomSD7mIDqGcxcd53C00=.d819e69b-0950-4a50-b1ad-eed88df5251e@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

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

  Update make/modules/jdk.compiler/Gensrc.gmk as suggested.
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/f1d6def8..019d0061

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

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

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

From jlahoda at openjdk.org  Mon Aug 11 09:43:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:43:36 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
 <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>
Message-ID: <1Hf1LjcgBDhCfj8Y6pvfRZXuEEpiBbUMNpvDLZ5_P9c=.135b2884-ea85-471e-816f-330e22f233cb@github.com>

On Mon, 28 Jul 2025 21:10:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting runtime checks, as suggested.
>
> make/langtools/tools/flagsgenerator/FlagsGenerator.java line 84:
> 
>> 82:                                            .forEach(target -> target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>())
>> 83:                                                                                    .computeIfAbsent(flagBit, _ -> new ArrayList<>())
>> 84:                                                                                    .add(flagName));
> 
> Instead of a dedicated loop to verify no overlaps, we can make the nested map `Map<Integer, String>` and fail fast whenever we detect a conflict, like:
> 
> var oldFlagName = target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>()).put(flagBit, flagName);
> if (oldFlagName != null) {
>     // Fail fast code
> }
> 
> I personally don't see a reason to collect all conflicting fields for a flag if any of these conflicts already causes a failure.

Its unlikely to be common in the long run, but there may be conflicts among more than two fields. Reporting all at once (rather than reporting one conflict, and after resolving reporting another) seems nicer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2266167613

From ihse at openjdk.org  Mon Aug 11 09:45:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:45:17 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version
In-Reply-To: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
Message-ID: <MLoxXxPx9_-kt5C_JhAzMDdNhs0UFZZu29yylQLQV6o=.8d709080-1f69-4d21-a97b-ec7ef151a0e6@github.com>

On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug description:
> 
> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
> 
> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

@dougxc @erikj79 Can you please review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26069#issuecomment-3173975603

From ihse at openjdk.org  Mon Aug 11 09:48:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:48:16 GMT
Subject: Integrated: 8361142: Improve custom hooks for makefiles
In-Reply-To: <91cuhK8a2VHENkKujTT5Q7CYxYjnK8qV3jULeLXi9jU=.d12fe818-ca41-4448-8a8f-120c60a219d7@github.com>
References: <91cuhK8a2VHENkKujTT5Q7CYxYjnK8qV3jULeLXi9jU=.d12fe818-ca41-4448-8a8f-120c60a219d7@github.com>
Message-ID: <Rj5h5H2cLDYPAxIBWF6Hrt5YAnul46clNhrJsBMbIjE=.c2993e65-dcc3-4d80-8eeb-a23c04508c40@github.com>

On Tue, 1 Jul 2025 07:46:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Add some additional and more fine-grained way in which custom makefiles can be integrated.

This pull request has now been integrated.

Changeset: 1fc0b016
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fc0b01601af454a0e871afce8ae0c9da1358f13
Stats:     38 lines in 8 files changed: 24 ins; 0 del; 14 mod

8361142: Improve custom hooks for makefiles

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Aug 11 09:52:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:52:13 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <2fhrymDxQIwpibGo5SC_-Y_4VxXC5Omsnj_GAbETK3A=.26b513c0-1c1f-460e-99e5-33d6548fdc83@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <2fhrymDxQIwpibGo5SC_-Y_4VxXC5Omsnj_GAbETK3A=.26b513c0-1c1f-460e-99e5-33d6548fdc83@github.com>
Message-ID: <uZn_5sFeCWzxzSm6Zov_rbVyJPI_UvlsO_DwXPqFb64=.5318b955-3e6f-4e75-9995-366125400750@github.com>

On Mon, 11 Aug 2025 08:57:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An alternative is to disable C4530; I can try that as well.

Well, that built and tested successfully at least. I've opened [JDK-8365231](https://bugs.openjdk.org/browse/JDK-8365231), so we can continue further discussion about that change separate from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3173995064

From jlahoda at openjdk.org  Mon Aug 11 09:57:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:57:03 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
 - Using EnumMap, as suggested.
 - Removing unnecessary delimited, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/019d0061..2095f574

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

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

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

From dnsimon at openjdk.org  Mon Aug 11 09:59:11 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 11 Aug 2025 09:59:11 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version
In-Reply-To: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
Message-ID: <fpnHpR2bgxF2sRx6UBaA2FG9NK_yaJwq8O2WsVqr2f4=.ec8c7790-fc9d-4c23-909d-9c987e6e987c@github.com>

On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug description:
> 
> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
> 
> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

LGTM.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26069#pullrequestreview-3104984155
PR Review: https://git.openjdk.org/jdk/pull/26069#pullrequestreview-3104984887

From ihse at openjdk.org  Mon Aug 11 10:02:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 10:02:25 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
Message-ID: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@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.

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

Commit messages:
 - 8365231: Don't build gtest with /EHsc

Changes: https://git.openjdk.org/jdk/pull/26721/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26721&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365231
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 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 duke at openjdk.org  Mon Aug 11 11:03:21 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 11:03:21 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom' build
 variant
Message-ID: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>

In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:

/jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
/jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
  402 |     ObjectCountEventSender::enable_requestable_event();
      |     ^~~~~~~~~~~~~~~~~~~~~~
/jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
  404 |     ObjectCountEventSender::disable_requestable_event();
      |     ^~~~~~~~~~~~~~~~~~~~~~


To reproduce:

sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
make -j hotspot CONF_NAME=cstm

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

Commit messages:
 - add check

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

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

From ihse at openjdk.org  Mon Aug 11 11:34:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:34:16 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <yptCke03-RgYbRaCn3QGhoAnT6SRCAd6FL5GhEOExZE=.b1122a1c-a425-4ece-93a8-2adf8159e084@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

Build changes look fine now

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3105399551

From cstein at openjdk.org  Mon Aug 11 11:35:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>

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

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

  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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/bf7b033b..b5112c32

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

  Stats: 30 lines in 2 files changed: 8 ins; 19 del; 3 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 cstein at openjdk.org  Mon Aug 11 11:35:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:13 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <45gc5UsWc5d6aePWF_7SSX0ERJTTvklTXBukRdjqhCc=.1cf0046e-b697-4fce-9751-e8eade48a49e@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

I updated both tests to be agnostic about the location to where `jtreg` puts library classes into. See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

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

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

From ihse at openjdk.org  Mon Aug 11 11:53:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:53:32 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@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>
Message-ID: <W9fd7acETIm00eLAGe0bFbH9KDJDdLqNVvSZ39jvWP0=.e3431808-2011-4bea-a544-f4654ec39b96@github.com>

On Fri, 1 Aug 2025 17:12:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove problemlisting
>
> make/StaticLibs.gmk line 163:
> 
>> 161: # $2: The launcher name
>> 162: define SetupRelauncher
>> 163:   $1_$2_LAUNCHER_ARGS_LINE :=  $$(shell cat $$(SUPPORT_OUTPUTDIR)/static-native/relaunchers/$1/$2-relauncher-arguments.txt)
> 
> `$(call ReadFile, ...)`
> 
> also, double space?

That was nicer. Had forgotten about it. Thanks!

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

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

From ihse at openjdk.org  Mon Aug 11 11:53:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:53:31 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v4]
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <yzZilmhHHlxVz4xjLSV47S9QcjTANrUnm2ABuLHAf4w=.bbabcde8-fd53-44cf-afb9-f5c167f42679@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 16 commits:

 - 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
 - Add cast for Windows
 - ... and 6 more: https://git.openjdk.org/jdk/compare/a60e523f...84585f7a

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

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=03
  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 duke at openjdk.org  Mon Aug 11 12:05:18 2025
From: duke at openjdk.org (duke)
Date: Mon, 11 Aug 2025 12:05:18 GMT
Subject: Withdrawn: 8339355: Test build/AbsPathsInImage.java fails configure
 with --enable-ccache
In-Reply-To: <PnppqUvzTvwIrNpG3ogi_Xg3uTGMq40IdtnzdCI5DaU=.8195daa0-ecb5-41a4-966a-2ee1a94e6e2d@github.com>
References: <PnppqUvzTvwIrNpG3ogi_Xg3uTGMq40IdtnzdCI5DaU=.8195daa0-ecb5-41a4-966a-2ee1a94e6e2d@github.com>
Message-ID: <1_QIVUsaHQthVscBRFfPKNS3_9SvTCrHk8jNaOdmK2g=.2bb86de4-ec49-4a82-a4ac-49b8a306dabb@github.com>

On Sat, 14 Jun 2025 03:51:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The debuginfo file will not ship to customers generally, so I think it's not necessary to check the debuginfo files contains absolutive path or not. And I can't find why the debuginfo file always contains workspace path info with --enable-ccache configure option.

This pull request has been closed without being integrated.

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

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

From erikj at openjdk.org  Mon Aug 11 13:10:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Aug 2025 13:10:17 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version
In-Reply-To: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
Message-ID: <FnN9lqGKIhuknQMRyBylJ53ERuTiMoi8Th_kLZfQZpQ=.5cb60101-e691-4a11-8498-2e7fcc92167d@github.com>

On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug description:
> 
> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
> 
> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

make/common/JavaCompilation.gmk line 42:

> 40: # Create classes that can run on the bootjdk
> 41: # -Xlint:-options is added to avoid "warning: [options] system modules path not set in conjunction with -source"
> 42: TARGET_RELEASE_BOOTJDK := -source $(OLDEST_BOOT_JDK_VERSION) -target $(OLDEST_BOOT_JDK_VERSION) -Xlint:-options

Line length?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26069#discussion_r2266708444

From erikj at openjdk.org  Mon Aug 11 13:15:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Aug 2025 13:15:12 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <VD8Wtp9pRvasu7szFks30yfEChOz-PWYu4UDITKcUuY=.0684362a-b04f-44fc-9301-216d374e5fc3@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

I think this looks ok, but it would be good if someone from Hotspot could confirm that this is an intended dependency.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26723#pullrequestreview-3105801914

From shade at openjdk.org  Mon Aug 11 13:43:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Aug 2025 13:43:11 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <GNq5m8A4TzqJVnqTzw2UgyFpg78ccagfO4bFtWlYp98=.c918ec8e-59ab-4593-a8cc-8680e6b0cc62@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

Looks like `ObjectCountEventSender` is JFR-specific, and `#if INCLUDE_SERVICES` in `objectCounterEventSender.cpp` is incorrect. If this is the only dependency between `jfr` and `services`, we should just fix `ObjectCountEventSender`.

Agree, @egahlin?

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

PR Comment: https://git.openjdk.org/jdk/pull/26723#issuecomment-3174898061

From ihse at openjdk.org  Mon Aug 11 13:44:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 13:44:32 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version [v2]
In-Reply-To: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
Message-ID: <jj9Gb_mU_SiQ02YXmk5jIFoZvYQOohr6DS80RTegmxY=.72d1e67f-b8a5-474d-bde8-39e17a83b939@github.com>

> From the bug description:
> 
> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
> 
> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

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

  Shorten line lengths

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26069/files
  - new: https://git.openjdk.org/jdk/pull/26069/files/f02d2077..03f97110

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

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

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

From ihse at openjdk.org  Mon Aug 11 13:44:33 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 13:44:33 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version [v2]
In-Reply-To: <FnN9lqGKIhuknQMRyBylJ53ERuTiMoi8Th_kLZfQZpQ=.5cb60101-e691-4a11-8498-2e7fcc92167d@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
 <FnN9lqGKIhuknQMRyBylJ53ERuTiMoi8Th_kLZfQZpQ=.5cb60101-e691-4a11-8498-2e7fcc92167d@github.com>
Message-ID: <fEG-1ZFNZlsM9InsGNhmar18QohGYOX-gd0RH5nfDj4=.b2215140-17af-44f2-8ee9-5d945e6df1c3@github.com>

On Mon, 11 Aug 2025 13:07:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Shorten line lengths
>
> make/common/JavaCompilation.gmk line 42:
> 
>> 40: # Create classes that can run on the bootjdk
>> 41: # -Xlint:-options is added to avoid "warning: [options] system modules path not set in conjunction with -source"
>> 42: TARGET_RELEASE_BOOTJDK := -source $(OLDEST_BOOT_JDK_VERSION) -target $(OLDEST_BOOT_JDK_VERSION) -Xlint:-options
> 
> Line length?

It was copied from old code, I did not even think of that. I also fixed some other too long lines in the vicinity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26069#discussion_r2266809988

From erikj at openjdk.org  Mon Aug 11 13:52:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Aug 2025 13:52:13 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version [v2]
In-Reply-To: <jj9Gb_mU_SiQ02YXmk5jIFoZvYQOohr6DS80RTegmxY=.72d1e67f-b8a5-474d-bde8-39e17a83b939@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
 <jj9Gb_mU_SiQ02YXmk5jIFoZvYQOohr6DS80RTegmxY=.72d1e67f-b8a5-474d-bde8-39e17a83b939@github.com>
Message-ID: <IAN4B9yZHOZOIfdjq9LAIcF-UgE6PHLQ7Ak9doc83_Q=.8bd023c8-5603-4da3-93b8-a1c7279a98bb@github.com>

On Mon, 11 Aug 2025 13:44:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> From the bug description:
>> 
>> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
>> 
>> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten line lengths

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26069#pullrequestreview-3105998320

From ihse at openjdk.org  Mon Aug 11 14:08:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:08:11 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <oAsSjEjg8z3c9AVmkOygg_BI9ibBqDded_KlEdz0DZM=.eb702809-1786-4289-9580-826319895e07@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

I think it is not that simple, unfortunately. I tried changing the ifdef but ran into additional issues. In gcTrace.cpp we have:

  virtual void do_cinfo(KlassInfoEntry* entry) {
    if (should_send_event(entry)) {
      ObjectCountEventSender::send(entry, _timestamp);
    }
  }

 private:
  bool should_send_event(const KlassInfoEntry* entry) const {
    double percentage_of_heap = ((double) entry->words()) / _total_size_in_words;
    return percentage_of_heap >= _size_threshold_percentage;
  }

which requires KlassInfoEntry (defined in src/hotspot/share/memory/heapInspection.hpp). When I tried to change that ifdef to INCLUDE_JFR, building with the `jfr` feature succeeded, but building with `services` failed.

So it seems there is some shared code here. Either heapInspection needs to be included if either `jfr` or `services` are enabled, or we should go the route of this PR and say that JFR is dependent on services. I think the latter seems cleaner.

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

PR Comment: https://git.openjdk.org/jdk/pull/26723#issuecomment-3175002573

From ihse at openjdk.org  Mon Aug 11 14:16:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:16:18 GMT
Subject: Integrated: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version
In-Reply-To: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
References: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>
Message-ID: <THpYqQasQ_m-J_J7MNKNftUcUB0OZEXW47lGG8_T4FM=.9ebb784f-42c4-429e-a7cc-102acbaa3f7e@github.com>

On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> From the bug description:
> 
> There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 
> 
> This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

This pull request has now been integrated.

Changeset: 23985c29
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23985c29b44b489472dcd3aad2cb98d9ce003a7b
Stats:     19 lines in 5 files changed: 8 ins; 3 del; 8 mod

8357979: Compile jdk.internal.vm.ci targeting the Boot JDK version

Reviewed-by: erikj, dnsimon

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

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

From ihse at openjdk.org  Mon Aug 11 14:21:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:21:12 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <RQI-6QjStR8-ZYf6DHL_cjSsE3GMQ4LH5MWtUfsFzjY=.38e40b11-8f1a-4f2d-8ee1-281862cb2a83@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>
Message-ID: <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@github.com>

On Fri, 1 Aug 2025 14:33:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove problemlisting
>
> make/ModuleWrapper.gmk line 82:
> 
>> 80:     TARGETS += $(LAUNCHERS_LIST)
>> 81:   endif
>> 82: endif
> 
> I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:
> 
> $(LAUNCHER_LIST): $$($1)
> TARGETS += $(LAUNCHER_LIST)
> 
> 
> Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.

Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.

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

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

From ihse at openjdk.org  Mon Aug 11 14:21:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:21:12 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <Tw5maFbJaPI5q0x-o44DqHICHN-dvxUQyUGaW4IbCLU=.abca2f27-d43f-48bd-9b92-c950002dbf0e@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>
Message-ID: <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@github.com>

On Mon, 11 Aug 2025 14:17:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/ModuleWrapper.gmk line 82:
>> 
>>> 80:     TARGETS += $(LAUNCHERS_LIST)
>>> 81:   endif
>>> 82: endif
>> 
>> I think it would be cleaner if this could be kept in LauncherCommon.gmk and avoid having ModuleWrapper.gmk involved in this. I think it can be done relatively easily. In SetupBuildLauncherBody, instead of constructing the variable `$(MODULE)_INCLUDED_LAUNCHERS`, declare dependencies for `$(LAUNCHER_LIST)`, something like this:
>> 
>> $(LAUNCHER_LIST): $$($1)
>> TARGETS += $(LAUNCHER_LIST)
>> 
>> 
>> Then put the the recipe for `$(LAUNCHER_LIST)` at the end of LauncherCommon.gmk. The $(LAUNCHER_LIST) value will sometimes be added to TARGETS multiple times, but that's ok I think.
>
> Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.

I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.

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

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

From shade at openjdk.org  Mon Aug 11 14:25:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Aug 2025 14:25:13 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <lTeNnw_FfFHGOzj385vPIFcHY6pBJ6AeLFNyDXik1OI=.79fc3374-582f-4d6d-9132-2969008e429c@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

Yes, all right.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26723#pullrequestreview-3106144792

From ihse at openjdk.org  Mon Aug 11 14:25:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:25:13 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <A71apIJFIXpdfoYfRLzA4q3qLNvmvj0A8_sQHqTpCBU=.bfeb0c07-3ce7-45e7-9cbd-3a6abb767756@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>
Message-ID: <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@github.com>

On Mon, 11 Aug 2025 14:18:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hm. I put it there since it was the only place where we could be sure we know *all* launchers for a module. I could have each launcher add itself to the list, but then I either need to check if it is already there, or we will just append to the list each time we rebuild. And we risk a race when several launchers build at the same time.
>
> I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.

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

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

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

From ihse at openjdk.org  Mon Aug 11 14:32:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 14:32:11 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <ivYP91cT2VkSCAAN2VStU_i6eokMvDm3k2JZO3S3hjg=.584556d5-f2c1-46cb-84c4-fdb6d0ad81db@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26723#pullrequestreview-3106181208

From duke at openjdk.org  Mon Aug 11 14:40:18 2025
From: duke at openjdk.org (duke)
Date: Mon, 11 Aug 2025 14:40:18 GMT
Subject: RFR: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <B9X8XcsZ3A-sjJksnnxs7_zNCLZlcousMuZc0zKHvds=.17031d41-c505-4fe1-aa01-b6984e260f52@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26723#issuecomment-3175160117

From duke at openjdk.org  Mon Aug 11 14:53:17 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 14:53:17 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <a921bj_3lczd_W-BOfh9x-Dtq62suBsjyn6zATEme2U=.2dd2466a-25fa-4410-94cb-855f78e36d3a@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

Some results:

| Features                         | Time1 (s) | Time2 (s) | Change (s) |
|---------------------------------|----------|----------|-------------|
| epsilongc                       | 490.77   | 489.50   | 1.27        |
| epsilongc cds                   | 546.27   | 537.91   | 8.36        |
| epsilongc compiler1             | 547.87   | 539.86   | 8.01        |
| epsilongc compiler2             | 785.18   | 735.13   | 50.05       |
| g1gc                            | 682.44   | 666.40   | 16.04       |
| epsilongc services              | 510.22   | 504.68   | 5.54        |
| epsilongc services jfr          | 675.49   | 636.87   | 38.62       |
| epsilongc jni-check              | 499.53   | 493.72   | 5.81        |
| epsilongc compiler1 jvmci       | 589.74   | 591.32   | -1.58       |
| epsilongc compiler2 jvmci       | 852.46   | 806.35   | 46.11       |
| epsilongc services jvmti        | 567.67   | 561.73   | 5.94        |
| epsilongc link-time-opt         | 535.96   | 526.00   | 9.97        |
| epsilongc management            | 508.63   | 504.53   | 4.10        |
| epsilongc opt-size              | 507.03   | 498.58   | 8.45        |
| parallelgc                      | 525.78   | 517.38   | 8.40        |
| serialgc                        | 512.59   | 511.88   | 0.71        |
| shenandoahgc                    | 739.44   | 722.72   | 16.72       |
| zgc                             | 681.20   | 672.28   | 8.92        |

- `Time1` is the time (sys+user) it takes to complete `make -h hotspot` with the precompiled headers in be25d3413b432b56e9789eae55920f1862008911 (>=400 includes in a `custom` build)
- `Time2`: same as `Time1`, with the precompiled headers having >=400 includes in a `custom` build with all features in the first column

So, the third column measures how much we improve by taking new precompiled headers due to a specific features. I'd say the following are worth keeping behind an include guard:
- `cds`
- `compiler1`
- `compiler2`
- `g1gc`
- `services`
- `jfr` ==> `services` (#26723)
- `jni-check`
- `link-time-opt`
- `opt-size`
- `parallelgc`
- `shenandoahgc`
- `zgc`

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175208900

From stuefe at openjdk.org  Mon Aug 11 15:41:19 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 11 Aug 2025 15:41:19 GMT
Subject: Integrated: 8364611: (process) Child process SIGPIPE signal
 disposition should be default
In-Reply-To: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
References: <zdsHwt8aEJR8V96Ar0I4foca1hu0RL70QEqsFHxPucQ=.d6cb8357-adc1-4968-9996-ecdb6375f6bf@github.com>
Message-ID: <uXXN0TqeSpoNZI-AZQCKYctsO-wuKFU1mZVxcRIvHpY=.760ce15c-30da-4a08-8f34-944dc3bd1d75@github.com>

On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> A customer reported an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changed the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it caused child processes to not react to SIGPIPE.
> 
> The system library is clearly at fault here, but the current workaround we recommend (pre-loading libjsig to interpose incorrect signal handling requests) is impractical for many customers. It is an okay solution when customers themselves have uncommon signal handling requirements; but for cases like these, where some version of system library does that, we should have a more pragmatic solution.
> 
> See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html .
> 
> The behavior is changed changed such that we set SIGPIPE to SIG_DFL in the child processes, and a regression test is added. Note: Regression test deliberately prints outs details for other POSIX signals too; this can be both a good ad-hoc analysis tool as well as a point where we add more tests for other signals, should we ever need to. This patch, however, is deliberately restricted to just fixing SIGPIPE.

This pull request has now been integrated.

Changeset: bdb1646a
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdb1646a1e39bae0535efe3f593e7fc0545e4114
Stats:     196 lines in 5 files changed: 195 ins; 0 del; 1 mod

8364611: (process) Child process SIGPIPE signal disposition should be default

Reviewed-by: erikj, rriggs

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

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

From ihse at openjdk.org  Mon Aug 11 15:52:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 15:52:21 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <a921bj_3lczd_W-BOfh9x-Dtq62suBsjyn6zATEme2U=.2dd2466a-25fa-4410-94cb-855f78e36d3a@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <a921bj_3lczd_W-BOfh9x-Dtq62suBsjyn6zATEme2U=.2dd2466a-25fa-4410-94cb-855f78e36d3a@github.com>
Message-ID: <Tplnzid0YavQQ_sYCUhVFTNq6cewn_KOo3zG_xGaZZA=.72f6cd9e-270b-4d6f-898e-f1b29cdce626@github.com>

On Mon, 11 Aug 2025 14:49:54 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> * `link-time-opt`
> 
> * `opt-size`

I thought these should not really affect the set of files compiled (or included, which is what matters here)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175481286

From duke at openjdk.org  Mon Aug 11 16:27:15 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 16:27:15 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <Tplnzid0YavQQ_sYCUhVFTNq6cewn_KOo3zG_xGaZZA=.72f6cd9e-270b-4d6f-898e-f1b29cdce626@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <a921bj_3lczd_W-BOfh9x-Dtq62suBsjyn6zATEme2U=.2dd2466a-25fa-4410-94cb-855f78e36d3a@github.com>
 <Tplnzid0YavQQ_sYCUhVFTNq6cewn_KOo3zG_xGaZZA=.72f6cd9e-270b-4d6f-898e-f1b29cdce626@github.com>
Message-ID: <7_2SHq1iU6SEIPWDiTaNhW6G0ChhcnsXtrVxMUgB0ts=.a407d743-9d86-4ab3-b905-3ea8cf8069f3@github.com>

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

>> Some results:
>> 
>> | Features                         | Time1 (s) | Time2 (s) | Change (s) |
>> |---------------------------------|----------|----------|-------------|
>> | epsilongc                       | 490.77   | 489.50   | 1.27        |
>> | epsilongc cds                   | 546.27   | 537.91   | 8.36        |
>> | epsilongc compiler1             | 547.87   | 539.86   | 8.01        |
>> | epsilongc compiler2             | 785.18   | 735.13   | 50.05       |
>> | g1gc                            | 682.44   | 666.40   | 16.04       |
>> | epsilongc services              | 510.22   | 504.68   | 5.54        |
>> | epsilongc services jfr          | 675.49   | 636.87   | 38.62       |
>> | epsilongc jni-check              | 499.53   | 493.72   | 5.81        |
>> | epsilongc compiler1 jvmci       | 589.74   | 591.32   | -1.58       |
>> | epsilongc compiler2 jvmci       | 852.46   | 806.35   | 46.11       |
>> | epsilongc services jvmti        | 567.67   | 561.73   | 5.94        |
>> | epsilongc link-time-opt         | 535.96   | 526.00   | 9.97        |
>> | epsilongc management            | 508.63   | 504.53   | 4.10        |
>> | epsilongc opt-size              | 507.03   | 498.58   | 8.45        |
>> | parallelgc                      | 525.78   | 517.38   | 8.40        |
>> | serialgc                        | 512.59   | 511.88   | 0.71        |
>> | shenandoahgc                    | 739.44   | 722.72   | 16.72       |
>> | zgc                             | 681.20   | 672.28   | 8.92        |
>> 
>> - `Time1` is the time (sys+user) it takes to complete `make -h hotspot` with the precompiled headers in be25d3413b432b56e9789eae55920f1862008911 (>=400 includes in a `custom` build)
>> - `Time2`: same as `Time1`, with the precompiled headers having >=400 includes in a `custom` build with all features in the first column
>> 
>> So, the third column measures how much we improve by taking new precompiled headers due to a specific features. I'd say the following are worth keeping behind an include guard:
>> - `cds`
>> - `compiler1`
>> - `compiler2`
>> - `g1gc`
>> - `services`
>> - `jfr` ==> `services` (#26723)
>> - `jni-check`
>> - `link-time-opt`
>> - `opt-size`
>> - `parallelgc`
>> - `shenandoahgc`
>> - `zgc`
>
>> * `link-time-opt`
>> 
>> * `opt-size`
> 
> I thought these should not really affect the set of files compiled (or included, which is what matters here)?

That's right @magicus, I rerun the script and I got only a `1.86s` improvements for `link-time-opt`. I checked the includes in `precompiled.hpp` and indeed nothing changes when the analyzer runs on a build with `link-time-opt`. So, exactly the same build, just different build times. That's most likely noise.

I'd say, as a criteria we could use is:
- Improvement > 10s (unlikely to be noise, but still possible)
- new headers added to `precompiled.hpp` is not empty

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3175758710

From duke at openjdk.org  Mon Aug 11 17:13:18 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 17:13:18 GMT
Subject: Integrated: 8365238: 'jfr' feature requires 'services' with 'custom'
 build variant
In-Reply-To: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
References: <1t7GxB8MYel7a1yE9ZFZTjxarzhsFb6vYV8h3rbrSg0=.5ab49f4b-ea78-4b53-bdb1-4a07103254e2@github.com>
Message-ID: <EgtfbKJl2HBG4U9svEL7mwk6suKKnkT51Qu7iqsh3NE=.80002ea3-213e-4731-bf88-eef7608abf44@github.com>

On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> In this PR I add an `autoconfigure` check to make sure that `jfr` is not built without the feature `services`, which would lead to the following error:
> 
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function ?virtual void VM_GC_SendObjectCountEvent::doit()?:
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:402:5: error: ?ObjectCountEventSender? has not been declared
>   402 |     ObjectCountEventSender::enable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:404:5: error: ?ObjectCountEventSender? has not been declared
>   404 |     ObjectCountEventSender::disable_requestable_event();
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> 
> 
> To reproduce:
> 
> sh configure --with-jvm-variants=custom --with-conf-name=cstm --enable-jvm-feature-jfr --enable-jvm-feature-serialgc
> make -j hotspot CONF_NAME=cstm

This pull request has now been integrated.

Changeset: e9e331b2
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9e331b2a957180dac2e9ce19a58d0a57d2f5dae
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8365238: 'jfr' feature requires 'services' with 'custom' build variant

Reviewed-by: erikj, shade, ihse

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

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

From erikj at openjdk.org  Mon Aug 11 17:23:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 11 Aug 2025 17:23:11 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <J6-ABR3b34n5S3W1zHMSr_TxRNAnRioKaN6oIZljRuo=.4f116d02-f16e-4b43-9f07-63207cba38e0@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>
Message-ID: <VLEgFaeir6ZFohN9Htx5dB1GXkEQiavrlbmp-8y_4ow=.213bb36b-5a36-45fb-acb0-cb164d70eef1@github.com>

On Mon, 11 Aug 2025 14:23:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I could also create a separate file for each launcher with a name pattern and gather up all these files in StaticLibs.gmk, but then I will get problems with left-over such files, for e.g. if incrementally building after removing a launcher. Not a common scenario, I agree, but it seems like a worse solution.
>
> 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.

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

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

From iris at openjdk.org  Mon Aug 11 17:38:12 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 11 Aug 2025 17:38:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
Message-ID: <3cVhuiuq1cW-XgONMnkCje3LI6yOMIxTmmiH5AStlTY=.e6a50bf3-0a7e-437b-bd66-3f6b59353b74@github.com>

On Mon, 11 Aug 2025 11:35:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   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

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3106980594

From duke at openjdk.org  Mon Aug 11 18:32:17 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 18:32:17 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <VqeG4BQJR-pUgHyg-XdoK8J9hesdKksi4OffXbJecMs=.591f2a30-4b27-4b9d-bb3c-c34cc37336f7@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

Just found a bug in the script, I'm rerunning all the combinations.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3176301836

From lmesnik at openjdk.org  Mon Aug 11 19:35:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:35:11 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
Message-ID: <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>

On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed makefiles

Thank you feedback, I explained the usage of 
 JTREG_JVMTI_STRESS_AGENT
and applied your changes.

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3107474883

From lmesnik at openjdk.org  Mon Aug 11 19:35:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Aug 2025 19:35:13 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <6BPt_Y_57yRWLC6iksvVGg3SkPKM98UAasfCcrAPFeo=.99d5dd24-39b4-4935-89c0-ff17aecd4b20@github.com>
Message-ID: <4zzzq381JNv2-LyGnqTZwxz1eLe-VPlqVcoF08Qw2V4=.ea35f8d3-c109-4614-8244-cf4a6f407f49@github.com>

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

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed makefiles
>
> make/RunTests.gmk line 881:
> 
>> 879: 
>> 880:   ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>> 881:     AGENT := $$(LIBRARY_PREFIX)JvmtiStressAgent$$(SHARED_LIBRARY_SUFFIX)=$$(JTREG_JVMTI_STRESS_AGENT)
> 
> I don't understand the usage scenario here. Are you supposed to run this like `make test JTREG=JVMTI_STRESS_AGENT=true`? If so, this will result in `-javaoption:'-agentpath:<test-image>/hotspot/jtreg/native/libJvmtiStressAgent.so=true` being sent to jtreg, and that looks sus. 
> 
> Or how should this be used? 
> 
> In fact, this option should be described in testing.md.

This is a jtreg agent options, I use it like
JTREG_JVMTI_STRESS_AGENT=debugger=false
or
JTREG_JVMTI_STRESS_AGENT=debugger=true,verbose
Any of options enable jvmti agent and parsed by it. 
I don't want to add 2 options, for hits. The JTREG_JVMTI_STRESS_AGENT=false doesn't make any sense. 

The options are defined by stress agent while makefile just propagate them to the agent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26360#discussion_r2267818671

From liach at openjdk.org  Mon Aug 11 20:59:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 20:59:15 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <KXtn3WXVuz86ZcGPq8IiAnqIPk1wHjdaJaNrOhftCJs=.6141fba9-5a2b-4a5e-87a4-369f237efd30@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

Looks good. This should have minimal impact to javac performance.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3107758710

From vromero at openjdk.org  Mon Aug 11 21:06:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Aug 2025 21:06:14 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <qVMlP3tdXgMt-C0xyUrl7s_ImSwWXJS9cTO67G9BzK4=.067244e8-0950-413a-b1b5-81d14d8313ff@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

very nice!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3107774416

From duke at openjdk.org  Mon Aug 11 21:37:14 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 11 Aug 2025 21:37:14 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <iZvKWx4ukMeRRnkuvO63EmY2W7iTYuKdqZm9iHXYIlM=.9ee2315f-c689-4b02-8340-99b36c3dc427@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

| Feature               | Baseline `precompiled.hpp` (Mean ?)  | Updated `precompiled.hpp` (Mean ?)  |
|-----------------------|---------------------|----------------------|
| epsilongc             | 505.78 ? 9.08        | 499.36 ? 3.21         |
| epsilongc cds         | 523.93 ? 9.42        | 510.68 ? 0.99         |
| epsilongc compiler1   | 514.89 ? 2.28        | 518.67 ? 14.22        |
| epsilongc compiler2   | 758.34 ? 5.56        | 736.65 ? 32.95        |
| g1gc                  | 674.96 ? 6.37        | 693.39 ? 23.25        |
| epsilongc services jfr| 707.45 ? 2.08        | 670.55 ? 1.50         |
| epsilongc jni-check   | 522.61 ? 1.82        | 517.46 ? 1.67         |
| epsilongc compiler1 jvmci | 604.92 ? 4.23    | 600.61 ? 8.79         |
| epsilongc compiler2 jvmci | 836.85 ? 7.40    | 792.07 ? 16.18        |
| epsilongc services jvmti | 549.48 ? 6.87     | 553.74 ? 7.67         |
| epsilongc management  | 486.56 ? 5.68        | 480.58 ? 4.59         |
| epsilongc opt-size    | 476.57 ? 1.87        | 476.71 ? 1.23         |
| parallelgc            | 497.28 ? 3.90        | 493.68 ? 2.19         |
| serialgc              | 477.84 ? 0.86        | 476.14 ? 1.32         |
| epsilongc services    | 476.99 ? 2.44        | 478.74 ? 3.47         |
| shenandoahgc          | 676.10 ? 5.35        | 623.43 ? 3.11         |
| zgc                   | 620.95 ? 1.84        | 621.86 ? 4.35         |

`?`: maximum and minimum measurements

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3176968277

From ihse at openjdk.org  Mon Aug 11 22:38:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 22:38:13 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <dsCSTYiibCNGIbQfHFIn10tx0QVMKcWsngtYVcherVM=.c95366ba-cb93-4fcd-b251-c6255a86eb69@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

This looks like regressions for c1 and G1..? And/or a lot more variability in build time. Any idea what is causing that?

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3177090836

From duke at openjdk.org  Tue Aug 12 00:54:14 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 12 Aug 2025 00:54:14 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <B4zNlxMti1eFOqITi42xpZs9peNw6r1uoe-tHY4C2q8=.9e7b0a0a-0971-48b4-9312-db18d20727c9@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

I'm starting to think the high variability is a quirk of my environment. I ran the builds in a virtualized machine and I'm probably experiencing erratic behavior under high load. 

I re-ran each combination fewer times (3, should still be enough to get an idea), and I'm observing more reasonable results:

| Feature                  | Baseline `precompiled.hpp`  | Updated `precompiled.hpp`           |
|----------------------------|-----------------|-----------------|
| epsilongc                  | 458.88 +/- 0.35 | 459.69 +/- 0.34 |
| epsilongc cds              | 501.63 +/- 0.35 | 501.58 +/- 0.57 |
| epsilongc compiler1        | 505.66 +/- 0.61 | 505.06 +/- 0.51 |
| epsilongc compiler2        | 725.91 +/- 0.41 | 692.25 +/- 0.40 |
| g1gc                       | 630.73 +/- 0.02 | 624.24 +/- 0.35 |
| epsilongc services jfr     | 625.54 +/- 1.45 | 592.37 +/- 1.00 |
| epsilongc jni-check        | 461.19 +/- 0.14 | 461.79 +/- 0.89 |
| epsilongc compiler1 jvmci  | 541.31 +/- 0.42 | 540.31 +/- 0.70 |
| epsilongc compiler2 jvmci  | 758.13 +/- 0.71 | 724.80 +/- 0.21 |
| epsilongc services jvmti   | 499.64 +/- 0.18 | 499.69 +/- 0.52 |
| epsilongc management       | 450.82 +/- 0.62 | 451.38 +/- 0.59 |
| epsilongc opt-size         | 446.44 +/- 0.56 | 446.16 +/- 0.12 |
| parallelgc                 | 467.23 +/- 0.19 | 466.89 +/- 0.41 |
| serialgc                   | 454.17 +/- 0.40 | 454.22 +/- 0.12 |
| epsilongc services         | 453.82 +/- 0.21 | 453.59 +/- 0.51 |
| shenandoahgc               | 658.17 +/- 0.50 | 647.44 +/- 0.40 |

[This](https://github.com/fandreuz/jdk-stuff/blob/master/script) is the script I used.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3177333952

From ihse at openjdk.org  Tue Aug 12 10:52:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Aug 2025 10:52:23 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
Message-ID: <ycY1xqs0hRcYDXbR7dcWJz120cG5qo1Px5sbsyOHGCM=.8da33a4f-4be1-4739-be6e-8a7ff95b6531@github.com>

On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - magic number: 400
>  - inline

Can you re-run the test with your updated and more stable testing setup with a default, out-of-the-box configured `server` variant, comparing the baseline PCH file with your updated one?

Your updated result seemed more reliable and probable, but they also do not differ that much from the baseline. I still saw a few improvements and no regression, so it might still be worth pursuing, but maybe your suggested change does not bring as much improvement as was first hinted at.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3178797213
PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3178802150

From rmarchenko at openjdk.org  Tue Aug 12 10:58:48 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 12 Aug 2025 10:58:48 GMT
Subject: RFR: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
Message-ID: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>

This change fixes the test artifact path on Alpine as `'[_*1000]'` is not recognized as a correct pattern, at least on Alpine 3.11.
BTW I'm not sure what `[_*1000]` is supposed to do, I guess it doesn't work as expected, regardless it's ok on most Linux.

Without this fix, on Alpine the command `make test-prebuilt` generated paths like the following:

Test report is stored in build/run-test-prebuilt/test-results/jtreg]test]hotspot]jtreg]tier1]common


Now it looks better:

Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_hotspot_jtreg_tier1_common

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

Commit messages:
 - 8365098: make/RunTests.gmk generates a wrong path to test artifacts on Alpine

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

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

From duke at openjdk.org  Tue Aug 12 11:32:42 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 12 Aug 2025 11:32:42 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
Message-ID: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>

> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
> 
> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
> 
> 
> linux-x64 GCC
> master      real 81.39 user 3352.15 sys 287.49
> JDK-8365053 real 81.94 user 3030.24 sys 295.82
> 
> linux-x64 Clang
> master      real 43.44 user 2082.93 sys 130.70
> JDK-8365053 real 38.44 user 1723.80 sys 117.68
> 
> linux-aarch64 GCC
> master      real 1188.08 user 2015.22 sys 175.53
> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
> 
> linux-aarch64 clang
> master      real 981.77 user 1645.05 sys 118.60
> JDK-8365053 real 791.96 user 1262.92 sys 101.50

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - conditional includes
 - variants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26681/files
  - new: https://git.openjdk.org/jdk/pull/26681/files/be25d341..c0b8c277

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

  Stats: 119 lines in 2 files changed: 114 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26681/head:pull/26681

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

From duke at openjdk.org  Tue Aug 12 12:30:18 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 12 Aug 2025 12:30:18 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v10]
In-Reply-To: <ycY1xqs0hRcYDXbR7dcWJz120cG5qo1Px5sbsyOHGCM=.8da33a4f-4be1-4739-be6e-8a7ff95b6531@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <H6THRQ-D2lidnpLwoloUL2J0C0aD52vG5H3DAmx49cA=.e55306be-617b-4d2c-9d53-1f23a50de589@github.com>
 <ycY1xqs0hRcYDXbR7dcWJz120cG5qo1Px5sbsyOHGCM=.8da33a4f-4be1-4739-be6e-8a7ff95b6531@github.com>
Message-ID: <8AAOto8QChuSmsPAhI98ld31aUpETaWhOL27HCnUPOg=.f2d82805-0d57-4aea-b2b1-646cd3296fb5@github.com>

On Tue, 12 Aug 2025 10:49:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Your updated result seemed more reliable and probable, but they also do not differ that much from the baseline. I still saw a few improvements and no regression, so it might still be worth pursuing, but maybe your suggested change does not bring as much improvement as was first hinted at.

I'd say individual improvements are a bit harder to observe in the kind of measurements I'm doing now, and the likelihood of measuring noise is higher. Also, the minimum inclusion threshold I'm using now is the same for all features, but that's unlikely to be optimal.

Maybe we could revert to the original approach (count inclusion for a typical build)? That proved to improve compile time, and I could hide non-standard headers behind an `#if`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3179118681

From davidalayachew at gmail.com  Tue Aug 12 00:16:45 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 11 Aug 2025 20:16:45 -0400
Subject: Got a warning treated as an error -- should I keep trying to build?
 And if so, how?
Message-ID: <CAA9v-_No-MQMDBVtONV-UKpbtj+aupn2OQaHnLEwHPxDKZa1Pg@mail.gmail.com>

Hello Build Dev Team,

I was trying to build the Valhalla repository off of the lworld branch, but
I ran into the following build error.

I went through the directions on this link --
https://openjdk.org/groups/build/doc/building.html

I went through the trouble-shooting section as well. It had useful
information, but nothing that clearly moved me forward.

I successfully ran bash configure. Here is the final output section

====================================================
A new configuration has been successfully created in
/home/david/valhalla/build/windows-x86_64-server-release
using default settings.

Configuration summary:
* Name:           windows-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 epsilongc g1gc jfr
jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc
vm-structs zgc'
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
* Version string: 25-internal-adhoc.david.valhalla (25-internal)
* Source date:    1754954438 (2025-08-11T23:20:38Z)

Tools summary:
* Environment:    cygwin version 3.6.4-1.x86_64, 2025-07-15 07:55 UTC;
windows version 10.0.26100.4652; prefix "/cygdrive"; root "C:\cygwin64"
* Boot JDK:       openjdk version "25-ea" 2025-09-16 OpenJDK Runtime
Environment (build 25-ea+34-3482) OpenJDK 64-Bit Server VM (build
25-ea+34-3482, mixed mode, sharing) (at
/cygdrive/c/users/david/_workspace_new/_programming/_jdk/jdk-25)
* Toolchain:      microsoft (Microsoft Visual Studio 2022)
* C Compiler:     Version 19.44.35214 (at
/cygdrive/c/progra~1/micros~4/2022/commun~1/vc/tools/msvc/1444~1.352/bin/hostx64/x64/cl.exe)
* C++ Compiler:   Version 19.44.35214 (at
/cygdrive/c/progra~1/micros~4/2022/commun~1/vc/tools/msvc/1444~1.352/bin/hostx64/x64/cl.exe)

Build performance summary:
* Build jobs:     8
* Memory limit:   15605 MB






And here is the output for the make images command.




Creating support/modules_cmds/jdk.jlink/jlink.exe from 1 file(s)
Creating support/modules_cmds/jdk.jpackage/jpackage.exe from 1 file(s)
Creating
jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncher.exe
from 24 file(s)
Creating support/modules_libs/jdk.jpackage/jpackage.dll from 23 file(s)
Creating support/modules_cmds/jdk.jlink/jmod.exe from 1 file(s)
Creating
jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/wixhelper.dll from
19 file(s)
Creating
jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/msiwrapper.exe
from 18 file(s)
Creating support/modules_cmds/jdk.jshell/jshell.exe from 1 file(s)
Creating
jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncherw.exe
from 24 file(s)
Creating support/modules_cmds/jdk.jstatd/jstatd.exe from 1 file(s)
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
error C2220: the following warning is treated as an error
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
make[3]: *** [modules/jdk.jdwp.agent/Lib.gmk:55:
/home/david/valhalla/build/windows-x86_64-server-release/support/native/jdk.jdwp.agent/libjdwp/debugInit.obj]
Error 1
make[3]: *** Waiting for unfinished jobs....
Creating support/modules_libs/jdk.net/extnet.dll from 1 file(s)
Creating support/modules_libs/jdk.security.auth/jaas.dll from 1 file(s)
Updating images/sec-bin.zip
Updating images/sec-windows-bin.zip
make[2]: *** [make/Main.gmk:182: jdk.jdwp.agent-libs] Error 2
make[2]: *** Waiting for unfinished jobs....
Updating images/jgss-windows-x64-bin.zip

ERROR: Build failed for target 'images' in configuration
'windows-x86_64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_native_jdk.jdwp.agent_libjdwp_debugInit.obj:
debugInit.c
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
error C2220: the following warning is treated as an error
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(186):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188):
warning C5287: operands are different enum types
'<unnamed-enum-JVMTI_VERSION_1>' and
'<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
silence this warning
C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(188):
note: to simplify migration, consider the temporary use of /Wv:18 flag with
the version of the compiler with which you used to build without warnings
   ... (rest of output omitted)

* All command lines available in
/home/david/valhalla/build/windows-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/home/david/valhalla/make/Init.gmk:144: main] Error 2
make: *** [/home/david/valhalla/make/PreInit.gmk:158: images] Error 2


Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250811/a503cd7f/attachment-0001.htm>

From kim.barrett at oracle.com  Tue Aug 12 14:45:46 2025
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 12 Aug 2025 10:45:46 -0400
Subject: Got a warning treated as an error -- should I keep trying to
 build? And if so, how?
In-Reply-To: <CAA9v-_No-MQMDBVtONV-UKpbtj+aupn2OQaHnLEwHPxDKZa1Pg@mail.gmail.com>
References: <CAA9v-_No-MQMDBVtONV-UKpbtj+aupn2OQaHnLEwHPxDKZa1Pg@mail.gmail.com>
Message-ID: <a21146ca-d778-45ae-ba05-b7d2df3a4fa7@oracle.com>

On 8/11/25 8:16 PM, David Alayachew wrote:
> Hello Build Dev Team,
> 
> I was trying to build the Valhalla repository off of the lworld branch, but I ran into the following build error.
> 
> I went through the directions on this link -- https://openjdk.org/groups/build/doc/building.html <https://openjdk.org/groups/build/doc/building.html>
> 
> I went through the trouble-shooting section as well. It had useful information, but nothing that clearly moved me forward.
[...]

> C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184): warning C5287: operands are different enum types '<unnamed-enum-JVMTI_VERSION_1>' and '<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to silence this warning

It looks like that was addressed in openjdk mainline here:
https://github.com/openjdk/jdk/pull/25293 - integrated 2025-05-21
Maybe that change hasn't been merged into the valhalla repository?

You can configure with --disable-warnings-as-error to suppress the error.



From duke at openjdk.org  Tue Aug 12 16:07:22 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 12 Aug 2025 16:07:22 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>
Message-ID: <kuv7d0cgK7Ft6JmIyZG08o3RFNloV-Mbp4TFqOGHt7k=.bd485178-a8ca-4792-8f79-22a0ce2b453c@github.com>

On Fri, 8 Aug 2025 06:30:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> So, we run gtests on Windows with `--gtest_catch_exceptions=0` which disables the inbuilt exception handler.
> 
> See issues
> 
> * https://bugs.openjdk.org/browse/JDK-8185734
> * https://bugs.openjdk.org/browse/JDK-8267138 (fixed an oversight in 8185734)
> 
> See more details in my [PR description for 8185734](https://github.com/openjdk/jdk/pull/1757#issue-765285610), that's why this all sounded so familiar.
> 
> The mechanism in place since 8267138 should be enough for my understanding. @swesonga, can you find out why this is not sufficient in your case? Is this option not passed on to your test?
> 
> > That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
> 
> In the libjvm code itself, we don't use C++ exceptions, and we catch all Windows SEH with `__try`/`__except`. We also don't want standard stack unwinding with these signals. So no need for `/EHxx`. My assumption is that the gtest framework itself uses C++ exceptions and therefore needs `/EHsc`. The documentation is not super clear on some aspects of this (https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model), but it says that for standard C++ exceptions to work `/EHsc` is needed.
> 
> > I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.
> 
> In my PR for 8184734, I wrote:
> 
> " In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream."
> 
> So it looks this was the first thing I tried back then, and it failed.

Thank you for this detailed background and explanation. Turns out we have 2 separate gtest runs happening, one that matches the GitHub actions test you pointed out and another that doesn't have the `--gtest_catch_exceptions=0` flag. I was focused on the latter scenario but based on your explanation, the correct resolution is for us to not run gtests without that flag. I will close this pull request and update our test infrastructure to remove that scenario.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3180036471

From duke at openjdk.org  Tue Aug 12 16:07:23 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 12 Aug 2025 16:07:23 GMT
Subject: Withdrawn: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <pgd5AG1HcqrX6EliKyW3oo1G46J1QTOWDdDRTwBjHzQ=.57dfcec7-7f5f-4ecc-8544-6eb76d72ecd4@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

This pull request has been closed without being integrated.

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

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

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@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 default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 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 cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 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: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

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

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

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From erikj at openjdk.org  Tue Aug 12 20:12:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Aug 2025 20:12:10 GMT
Subject: RFR: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
In-Reply-To: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
References: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
Message-ID: <CUxp-nURcVu6XvL5R2IPim7YdgZKWNjqbKrraBFmMog=.d4bbae13-5945-4ca6-ad2e-c331816dafba@github.com>

On Tue, 12 Aug 2025 10:51:06 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes the test artifact path on Alpine as `'[_*1000]'` is not recognized as a correct pattern, at least on Alpine 3.11.
> 
> Without this fix, on Alpine the command `make test-prebuilt` generated paths like the following:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg]test]hotspot]jtreg]tier1]common
> 
> 
> Now it looks better:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_hotspot_jtreg_tier1_common
> 
> All checks (tier1) are passed.

The explanation for this can be found here: 
https://mail.openjdk.org/pipermail/build-dev/2017-November/020334.html

Given that we are no longer supporting Solaris in mainline, it should be ok to remove it.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26742#pullrequestreview-3112620484

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 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: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@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...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

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

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 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: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@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...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

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

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 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: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@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...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From jlahoda at openjdk.org  Wed Aug 13 08:11:26 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 08:11:26 GMT
Subject: Integrated: 8362885: A more formal way to mark javac's Flags that
 belong to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <xJV57e7yqzyoMEeWxkCRZ_7k7D3Yuj9o0vSNrb6w7bs=.f6b90449-8b93-4351-895a-80a8d79ce8e7@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

This pull request has now been integrated.

Changeset: 72e22b4d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72e22b4de59a18f83c75be9a51fd99726f77f6f6
Stats:     495 lines in 8 files changed: 362 ins; 80 del; 53 mod

8362885: A more formal way to mark javac's Flags that belong to a specific Symbol type only

Reviewed-by: ihse, liach, vromero, mcimadamore, erikj

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

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

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 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: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@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...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

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

From stuefe at openjdk.org  Wed Aug 13 10:01:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 13 Aug 2025 10:01:20 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <kuv7d0cgK7Ft6JmIyZG08o3RFNloV-Mbp4TFqOGHt7k=.bd485178-a8ca-4792-8f79-22a0ce2b453c@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
 <lv3wzJd-PC_yotO6Ht5QOnhwjFSJfsZ94PhvghYM5vY=.6af98d06-06f1-4728-b13d-b8dc20cfc7da@github.com>
 <kuv7d0cgK7Ft6JmIyZG08o3RFNloV-Mbp4TFqOGHt7k=.bd485178-a8ca-4792-8f79-22a0ce2b453c@github.com>
Message-ID: <txnBTFKYZHBQUZJ5eF7eDfkJeC4cVCxXJygs1I9f2SM=.22ccef46-4c3e-48b5-8714-15765040fb93@github.com>

On Tue, 12 Aug 2025 16:04:06 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> So, we run gtests on Windows with `--gtest_catch_exceptions=0` which disables the inbuilt exception handler.
>> 
>> See issues 
>> - https://bugs.openjdk.org/browse/JDK-8185734  
>> - https://bugs.openjdk.org/browse/JDK-8267138 (fixed an oversight in 8185734)
>> 
>> See more details in my [PR description for 8185734](https://github.com/openjdk/jdk/pull/1757#issue-765285610), that's why this all sounded so familiar.
>> 
>> The mechanism in place since 8267138 should be enough for my understanding. @swesonga, can you find out why this is not sufficient in your case? Is this option not passed on to your test?
>> 
>>> That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
>> 
>> In the libjvm code itself, we don't use C++ exceptions, and we catch all Windows SEH with `__try`/`__except`. We also don't want standard stack unwinding with these signals. So no need for `/EHxx`. My assumption is that the gtest framework itself uses C++ exceptions and therefore needs `/EHsc`. The documentation is not super clear on some aspects of this (https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model), but it says that for standard C++ exceptions to work `/EHsc` is needed.
>> 
>>> I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.
>> 
>> In my PR for 8184734, I wrote: 
>> 
>> " In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream."
>> 
>> So it looks this was the first thing I tried back then, and it failed.
>
>> So, we run gtests on Windows with `--gtest_catch_exceptions=0` which disables the inbuilt exception handler.
>> 
>> See issues
>> 
>> * https://bugs.openjdk.org/browse/JDK-8185734
>> * https://bugs.openjdk.org/browse/JDK-8267138 (fixed an oversight in 8185734)
>> 
>> See more details in my [PR description for 8185734](https://github.com/openjdk/jdk/pull/1757#issue-765285610), that's why this all sounded so familiar.
>> 
>> The mechanism in place since 8267138 should be enough for my understanding. @swesonga, can you find out why this is not sufficient in your case? Is this option not passed on to your test?
>> 
>> > That led me to wonder why, on Windows, we build libgtest and rebuild libjvm with exceptions enabled, by using -EHsc instead of no -EH option as done for the non-gtest libjvm?
>> 
>> In the libjvm code itself, we don't use C++ exceptions, and we catch all Windows SEH with `__try`/`__except`. We also don't want standard stack unwinding with these signals. So no need for `/EHxx`. My assumption is that the gtest framework itself uses C++ exceptions and therefore needs `/EHsc`. The documentation is not super clear on some aspects of this (https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model), but it says that for standard C++ exceptions to work `/EHsc` is needed.
>> 
>> > I was concerned that this might effectively undo JDK-8185734, since the suggestion in JBS was to conditionalize some code on GTEST_HAS_SEH being true. But it looks like the actual change didn't do that.
>> 
>> In my PR for 8184734, I wrote:
>> 
>> " In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream."
>> 
>> So it looks this was the first thing I tried back then, and it failed.
> 
> Thank you for this detailed background and explanation. Turns out we have 2 separate gtest runs happening, one that matches the GitHub actions test you pointed out and another that doesn't have the `--gtest_catch_exceptions=0` flag. I was focused on the latter scenario but based on your explanation, the correct resolution is for us to not run gtests without that flag. I will close this pull request and update our test infrastructure to remove that scenario.

@swesonga Thank you for the update! Good to see that we have understood everything.

I admit having to control this externally instead of having this knowledge baked into the launcher at build time is less satisfactory. What would be helpful would be if we could have a warning in the test when running on Windows.

Edit: Also, good analysis, sorry that it did not result in a patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3183089466

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan 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: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > 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.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 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: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@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...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

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

From mhaessig at openjdk.org  Wed Aug 13 13:30:47 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 13 Aug 2025 13:30:47 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle Java
 extension
Message-ID: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>

This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.

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

Commit messages:
 - make/ide/vscode: add basic configuration for Oracle Java extension

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan 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: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From jlahoda at openjdk.org  Wed Aug 13 14:11:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 14:11:10 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension
In-Reply-To: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
Message-ID: <99y0kw0loER23cXnLl2k88BEVY7XorBViF6SGADgNRY=.09ee46af-2a6b-4c95-8d26-f76117bb1f7f@github.com>

On Wed, 13 Aug 2025 13:22:21 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.

Looks like a reasonable direction to me. I would suggest to drop:

"jdk.advanced.disable.nbjavac": true,


while it may be good for some, it may lead to surprising effects for others people that don't know about this setting.

Also, including:

		"jdk.java.onSave.organizeImports": false


might make sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/26759#issuecomment-3184094444

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@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:

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 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  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

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

From mhaessig at openjdk.org  Wed Aug 13 14:23:37 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 13 Aug 2025 14:23:37 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v2]
In-Reply-To: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
Message-ID: <_HedHy5F966CKB-J_xRbvt_gLfCk9BIlNvk5H5WpwHc=.2b9e787f-64be-4cb5-9ce4-5c6907ac4b28@github.com>

> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Prevent organizing imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26759/files
  - new: https://git.openjdk.org/jdk/pull/26759/files/6a4d9efb..277a590d

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

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

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

From fgao at openjdk.org  Wed Aug 13 14:25:26 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 13 Aug 2025 14:25:26 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with auto-var-init
 pattern
Message-ID: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>

`-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].

`vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].

Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.

I did not encounter similar problems when building with Clang-16 [6].

This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding

Testing (combined with https://github.com/openjdk/jdk/pull/26577):
1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines

[1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
[2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
[3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
[4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
[5] https://bugs.openjdk.org/browse/JDK-8364185
[6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

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

Commit messages:
 - 8365312: __builtin_clear_padding not supported for variable length aggregates

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

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

From mhaessig at openjdk.org  Wed Aug 13 14:27:12 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 13 Aug 2025 14:27:12 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension
In-Reply-To: <99y0kw0loER23cXnLl2k88BEVY7XorBViF6SGADgNRY=.09ee46af-2a6b-4c95-8d26-f76117bb1f7f@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <99y0kw0loER23cXnLl2k88BEVY7XorBViF6SGADgNRY=.09ee46af-2a6b-4c95-8d26-f76117bb1f7f@github.com>
Message-ID: <hWe0uDs4CA6Mt_RYQUr5seLcPKQLnqOHkhFuTzP54MY=.a7a7bf1d-8fef-469e-a2a5-c93e8e65976e@github.com>

On Wed, 13 Aug 2025 14:08:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I would suggest to drop: `"jdk.advanced.disable.nbjavac": true,`

Can you elaborate on the surprising results? When developing the JDK we will most probably use features not supported by the `nbjavac`.

> Also, including:`"jdk.java.onSave.organizeImports": false` might make sense.

Good point. That will lead to unwanted changes if true.

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

PR Comment: https://git.openjdk.org/jdk/pull/26759#issuecomment-3184151430

From fgao at openjdk.org  Wed Aug 13 14:31:10 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 13 Aug 2025 14:31:10 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <bR2b9E3Nz32etEryenojfCQCmvzS0_cO5V81pxike34=.b2412beb-f913-44de-be58-fb818cd2db9a@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

HI @jaikiran , could you please help test the combination of this PR and https://github.com/openjdk/jdk/pull/26577 in your CI? It would be very helpful to verify them together. Thanks in advance!

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3184170316

From jpai at openjdk.org  Wed Aug 13 15:55:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Aug 2025 15:55:11 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <bR2b9E3Nz32etEryenojfCQCmvzS0_cO5V81pxike34=.b2412beb-f913-44de-be58-fb818cd2db9a@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <bR2b9E3Nz32etEryenojfCQCmvzS0_cO5V81pxike34=.b2412beb-f913-44de-be58-fb818cd2db9a@github.com>
Message-ID: <Ib9CBekCqIo9nIdQaQ4PF2PI-ZKbJjb92j3E5yeDZ-A=.e438bf58-3f48-44e1-a84d-289dc4409f0d@github.com>

On Wed, 13 Aug 2025 14:28:56 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> HI @jaikiran , could you please help test the combination of this PR and https://github.com/openjdk/jdk/pull/26577 in your CI? It would be very helpful to verify them together. Thanks in advance!

Hello @fg1417,

> HI @jaikiran , could you please help test the combination of this PR and #26577 in your CI? It would be very helpful to verify them together. Thanks in advance!

I have triggered a tier1, tier2, tier3 run in our CI with the changes in this PR and the ones in https://github.com/openjdk/jdk/pull/26577, on top of latest JDK master branch. The tests take a while to complete and I will update this PR once I have the results.

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3184481047

From erikj at openjdk.org  Wed Aug 13 20:35:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 20:35:10 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <TPQHqLcn7m1FdTTpaLDjDedQysQ0llWBQRVmqXJsbrA=.b6abefd8-b75b-4a8b-b438-3fa47d6d2a65@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

Looks ok from a build perspective pending test results from Jaikiran.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26755#pullrequestreview-3117600475

From kbarrett at openjdk.org  Thu Aug 14 06:51:17 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 06:51:17 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

Changes requested by kbarrett (Reviewer).

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

> 958:             # avoids the use of unsupported `__builtin_clear_padding` for variable
> 959:             # length aggregates
> 960:             if test "x$TOOLCHAIN_TYPE" = xgcc ; then

We only add `-ftrival-auto-var-init=pattern` when "x$DEBUG_LEVEL" != "xrelease", e.g. only in
debug builds.  I think we should only add the `=zero` flag in debug builds and nothing in release
builds here too.

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

PR Review: https://git.openjdk.org/jdk/pull/26755#pullrequestreview-3119223806
PR Review Comment: https://git.openjdk.org/jdk/pull/26755#discussion_r2275639166

From jpai at openjdk.org  Thu Aug 14 07:40:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 07:40:17 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <HbnVGMd7Tg8FFQsbTtHfSnX8yEQK7kHLIghv-2cGvUY=.8b5a6d7f-0b32-4215-b91b-f34f021a5b0d@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

tier1, tier2, tier3 testing of this and https://github.com/openjdk/jdk/pull/26577 completed without any related failures. Once the PR is approved (I see Kim has suggested some changes), I will run a final round of tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3187299715

From davidalayachew at gmail.com  Thu Aug 14 08:27:31 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 14 Aug 2025 04:27:31 -0400
Subject: Got a warning treated as an error -- should I keep trying to
 build? And if so, how?
In-Reply-To: <a21146ca-d778-45ae-ba05-b7d2df3a4fa7@oracle.com>
References: <CAA9v-_No-MQMDBVtONV-UKpbtj+aupn2OQaHnLEwHPxDKZa1Pg@mail.gmail.com>
 <a21146ca-d778-45ae-ba05-b7d2df3a4fa7@oracle.com>
Message-ID: <CAA9v-_MjMZR_pmWV6=j-sDGqa0SugyaSE+aX_EjROJt299BFtQ@mail.gmail.com>

Thanks, it worked! All I needed to do was run the flag you gave me on my
bash configure, then reattempt the make images command, and it worked!
Building the JDK has gotten easier than the last time I tried it.

On Tue, Aug 12, 2025 at 10:46?AM Kim Barrett <kim.barrett at oracle.com> wrote:

> On 8/11/25 8:16 PM, David Alayachew wrote:
> > Hello Build Dev Team,
> >
> > I was trying to build the Valhalla repository off of the lworld branch,
> but I ran into the following build error.
> >
> > I went through the directions on this link --
> https://openjdk.org/groups/build/doc/building.html <
> https://openjdk.org/groups/build/doc/building.html>
> >
> > I went through the trouble-shooting section as well. It had useful
> information, but nothing that clearly moved me forward.
> [...]
>
> >
> C:\cygwin64\home\david\valhalla\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c(184):
> warning C5287: operands are different enum types
> '<unnamed-enum-JVMTI_VERSION_1>' and
> '<unnamed-enum-JVMTI_VERSION_MASK_INTERFACE_TYPE>'; use an explicit cast to
> silence this warning
>
> It looks like that was addressed in openjdk mainline here:
> https://github.com/openjdk/jdk/pull/25293 - integrated 2025-05-21
> Maybe that change hasn't been merged into the valhalla repository?
>
> You can configure with --disable-warnings-as-error to suppress the error.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250814/991f2d57/attachment-0001.htm>

From ihse at openjdk.org  Thu Aug 14 09:16:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:16:20 GMT
Subject: RFR: 8364664: gtest death tests failing on Windows
In-Reply-To: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
References: <mJItbGz_6ZHG_NHl7qDUmfXgn_JjJfzpwJmA8bOxtyY=.264c18a0-49d0-4445-9031-c16ca6b48c21@github.com>
Message-ID: <F7sC4XduR5OW7-ZwaM6fTWK92tg1fjpRCV5YsLIhx8I=.e41e3f78-df3b-4a4b-9ce8-a7071d56aa40@github.com>

On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death tests to fail on Windows with the error message "Caught std::exception-derived exception escaping the death test statement. Exception message: unknown file: error: SEH exception with code 0xc0000005 thrown in the test body." The error message is from the catch block in https://github.com/google/googletest/blob/v1.14.0/googletest/include/gtest/internal/gtest-death-test-internal.h#L198-L212
> 
> In the failing death tests, the gtests start another process and expect the child process to be terminated by JVM error handling code. However, the structured exception handling code in the googletest code ends up getting executed instead. The death tests expect execution to continue after the instruction that triggered the exception by writing to the poissoned page. This change proposes build Windows gtests without structured exception handling to avoid changing the flow of exceptions in OpenJDK test code. The effect of this change is to stop using the  [SEH path in the HandleSehExceptionsInMethodIfSupported method](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2603) and [directly start the test](https://github.com/google/googletest/blob/v1.14.0/googletest/src/gtest.cc#L2612).
> 
> All the Windows gtests now pass with this change.

Is there some way we can patch the launcher to set this option automatically? I agree too that it is not ideal that the caller needs to know to pass it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26661#issuecomment-3187681378

From ihse at openjdk.org  Thu Aug 14 09:31:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:31:17 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
Message-ID: <roJ4dlKIZmldgH1SLmn58wGPERh48P-p_JbUSW6nR1A=.9a7236ea-3079-481d-a7b2-897c7e755b65@github.com>

On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - conditional includes
>  - variants

If I recall correctly the original approach was even simpler: I counted the number of `#include`s in the C++ source files, not in the dependency files of a particular build. Crude but effective, and left out discussions about differences between platforms and feature configurations. And then I had to do some adjustments for Windows where my approach of excluding inline files did not hold and caused a regression.

I think your approach seems more valid, but maybe we get stuck in details then instead...

But then again, this is basically an optimization problem (even if it is not about running code in the JVM, but about optimizing build speed) so there is no way around the mantra of measure, measure and measure again.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3187744222

From ihse at openjdk.org  Thu Aug 14 09:42:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:42:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v3]
In-Reply-To: <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <O9-mye3CK00INdJtzKCT4MAh4f8k76D-LxGWnJnKboQ=.f6fd9539-cdd3-4bef-bf63-25ae2bdc16a2@github.com>
 <oO0w2mjzbdgtkBcmvrBsHQN_MCxTKZR6PVWZUt2JTRQ=.3e5d7937-ed6a-4306-804c-10f73bcb3bd8@github.com>
Message-ID: <Xr9N-eZR6lWVA4Oxw6RVLY-xpry6Cb-wFyKHxUuUaqI=.0d4d7aac-b6c9-492b-aa26-f34319467a9d@github.com>

On Mon, 11 Aug 2025 19:32:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Thank you feedback, I explained the usage of
> JTREG_JVMTI_STRESS_AGENT
> and applied your changes.

I can't see any updates to this PR? Did you forget to push your commits?

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3187804873

From ihse at openjdk.org  Thu Aug 14 09:46:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:46:12 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>
Message-ID: <9e3JH2ZJGP1wW1i5pA56IHk2MKaOu-FTFv_xZrUlFu4=.5a879e52-753d-4b0d-b806-a9ae2de6104d@github.com>

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

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> make/autoconf/flags-cflags.m4 line 960:
> 
>> 958:             # avoids the use of unsupported `__builtin_clear_padding` for variable
>> 959:             # length aggregates
>> 960:             if test "x$TOOLCHAIN_TYPE" = xgcc ; then
> 
> We only add `-ftrival-auto-var-init=pattern` when "x$DEBUG_LEVEL" != "xrelease", e.g. only in
> debug builds.  I think we should only add the `=zero` flag in debug builds and nothing in release
> builds here too.

I agree. Make sure to use the same test (DEBUG_LEVEL != release) to catch both fast and slow debug builds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26755#discussion_r2276126511

From ihse at openjdk.org  Thu Aug 14 09:50:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:50:12 GMT
Subject: RFR: 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: <vulefHwW-2HPnQigeK1oVi9bebpUW_tgqBjV39Vajrc=.574b02df-7fd0-4f75-ad69-418e620ddefc@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.

@kimbarrett Any opinions?

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3187826145

From ihse at openjdk.org  Thu Aug 14 09:54:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:54:12 GMT
Subject: RFR: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
In-Reply-To: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
References: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
Message-ID: <aNVrtxRwGC5dW7-lX6zu5n9PxrPxrxLW79pIxm1Exok=.5824c86d-bea1-4805-bcdb-eb8b031563ea@github.com>

On Tue, 12 Aug 2025 10:51:06 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes the test artifact path on Alpine as `'[_*1000]'` is not recognized as a correct pattern, at least on Alpine 3.11.
> 
> Without this fix, on Alpine the command `make test-prebuilt` generated paths like the following:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg]test]hotspot]jtreg]tier1]common
> 
> 
> Now it looks better:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_hotspot_jtreg_tier1_common
> 
> All checks (tier1) are passed.

LTGM. Actually, an improvement on all platforms, not only Alpine (sans Solaris...)

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26742#pullrequestreview-3119910398

From ihse at openjdk.org  Thu Aug 14 09:54:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:54:14 GMT
Subject: RFR: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
In-Reply-To: <CUxp-nURcVu6XvL5R2IPim7YdgZKWNjqbKrraBFmMog=.d4bbae13-5945-4ca6-ad2e-c331816dafba@github.com>
References: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
 <CUxp-nURcVu6XvL5R2IPim7YdgZKWNjqbKrraBFmMog=.d4bbae13-5945-4ca6-ad2e-c331816dafba@github.com>
Message-ID: <vM2Mqm41QOdv28_n1X12SzjigAJSUB0U9OmQjiv1bYo=.e7e688fe-09d9-486d-afd8-7975fea048db@github.com>

On Tue, 12 Aug 2025 20:09:15 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The explanation for this can be found here:
> https://mail.openjdk.org/pipermail/build-dev/2017-November/020334.html

Thank you for digging that out! I was just about to check why in the world we could ever have written something so wonky. I had happily completely forgotten how I wrestled with bad tooling on Solaris.

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

PR Comment: https://git.openjdk.org/jdk/pull/26742#issuecomment-3187837407

From ihse at openjdk.org  Thu Aug 14 09:57:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:57:14 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: <vDnzZGlusvloG4xLlr3ImY7SB2Tkt22rVaeHuthBtDk=.c2fa65b8-3078-493c-b6eb-b7c5e64baeb4@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.

Aha, now I understand what you mean! My mind slipped -- I read `LauncherCommon.gmk` but thought `SetupBuildLauncher`. But you mean just store it in the top-level of the actual makefile that is included by all launchers. Yeah, that could definitely work.

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

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

From duke at openjdk.org  Thu Aug 14 10:00:10 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 10:00:10 GMT
Subject: RFR: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
In-Reply-To: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
References: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
Message-ID: <tc1A-ek94IWYCN2r6lS_-L5L2b9w44ERLsNlEPDRI7k=.cc343163-6b38-4c0e-8b8b-6b2795278933@github.com>

On Tue, 12 Aug 2025 10:51:06 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes the test artifact path on Alpine as `'[_*1000]'` is not recognized as a correct pattern, at least on Alpine 3.11.
> 
> Without this fix, on Alpine the command `make test-prebuilt` generated paths like the following:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg]test]hotspot]jtreg]tier1]common
> 
> 
> Now it looks better:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_hotspot_jtreg_tier1_common
> 
> All checks (tier1) are passed.

@wkia 
Your change (at version 8569ea3c355a80b0b938cb53236178b7bb3a505a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26742#issuecomment-3187857957

From duke at openjdk.org  Thu Aug 14 11:25:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 11:25:00 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
Message-ID: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>

Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
Tested locally in a worktree and normal repository. It produces:

 <component name="VcsDirectoryMappings">
    <mapping directory="$PROJECT_DIR$" vcs="Git" />
    <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
  </component>

in both cases, as expected.

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

Commit messages:
 - Simple fix (just checking file)

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

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

From vyazici at openjdk.org  Thu Aug 14 12:03:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 14 Aug 2025 12:03:12 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <KQrIZQoqb2FdLu7i6eUCI0fzR_cBDr_XQliY28KlVxE=.3be8aad2-e1c5-4056-8ccc-b3ea81e9fe29@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120319106

From magnus.ihse.bursie at oracle.com  Thu Aug 14 12:22:17 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 14:22:17 +0200
Subject: Fwd: DALEQ: An Open-Source Tool for Assessing Java Binary Equivalence
In-Reply-To: <ME2PR01MB50587C866BB9ABD074F2F3C0A82FA@ME2PR01MB5058.ausprd01.prod.outlook.com>
References: <ME2PR01MB50587C866BB9ABD074F2F3C0A82FA@ME2PR01MB5058.ausprd01.prod.outlook.com>
Message-ID: <aa879929-27fa-49d5-bc66-42b0e9c00fc9@oracle.com>

While not directly applicable to the JDK, this is still interesting from 
a general reproducible build perspective.

/Magnus

-------- Forwarded Message --------
Subject: 	DALEQ: An Open-Source Tool for Assessing Java Binary Equivalence
Date: 	Fri, 8 Aug 2025 03:42:47 +0000
From: 	Jens Dietrich via rb-general 
<rb-general at lists.reproducible-builds.org>
Reply-To: 	General discussions about reproducible builds 
<rb-general at lists.reproducible-builds.org>
To: 	rb-general at lists.reproducible-builds.org 
<rb-general at lists.reproducible-builds.org>
CC: 	Jens Dietrich <jens.dietrich at vuw.ac.nz>



Introducing DALEQ: An Open-Source Tool for Assessing Java Binary Equivalence

We?re excited to announce the release of DALEQ ? a new open-source tool 
for analyzing and comparing Java binaries. DALEQ is designed to help 
developers, security researchers, and build engineers assess whether two 
.jar files built from the same source code are semantically equivalent, 
even when they?re not bitwise identical. This is particularly useful for 
comparing ?jars from Maven Central and jars produced via reproducible 
builds, or ?generated by services like Oracle?s build-from-source or 
Google?s Assured OSS. Although tools like diff or hash-based checks can 
detect binary differences, they don?t explain why binaries differ, or 
whether those differences matter. Bytecode-level differences can be 
caused by changes in compilers or build pipelines ? not necessarily by 
compromised builds. DALEQ helps distinguish harmless variation from 
meaningful divergence.

How DALEQ Works

DALEQ focuses on Java bytecode comparison, though it can also analyze 
resources and metadata in jars. At its core, DALEQ uses a datalog engine 
(Souffl?) ? the same kind of logic-based analysis engine used in systems 
like CodeQL ? to normalize and compare bytecode structures. Key features 
include:

- Bytecode normalization to reduce irrelevant build differences
- Semantic diffing that identifies and explains non-equivalent instructions
- Provenance tracking: For equivalent files, DALEQ shows how equivalence 
was derived via datalog rules, for non-equivalent files, it provides 
bytecode-level diffs

DALEQ also verifies whether the underlying source code inputs are the 
same (or at least equivalent, tolerating some variations in comments and 
formatting) and includes integrations with existing tools like the 
standard javap disassembler. It supports extensibility through a plugin 
system.

Real-World Evaluation

DALEQ builds on our earlier research into levels of binary equivalence. 
We evaluated the tool using real-world .jar files from Oracle and 
Google, both of whom independently rebuild Java packages from source. 
The results are encouraging: DALEQ was able to classify 85?90% of .class 
files that were not bitwise identical as still being semantically 
equivalent, with supporting provenance.

Learn More

You can try out DALEQ now on GitHub: https://github.com/binaryeq/daleq/
A detailed technical paper describing DALEQ and our evaluation: 
https://arxiv.org/abs/2508.01530
A technical paper describing the conceptual approach of levels of binary 
equivalence: https://arxiv.org/abs/2410.08427?(to be presented at 
ICSME?25 <https://conf.researchr.org/home/icsme-2025>)


Jens Dietrich (Associate Professor at Victoria University of Wellington)

Behnaz Hassanshahi (Principal Researcher and Tech Lead at Oracle, Oracle 
Labs Brisbane)

  *






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250814/d210ba00/attachment-0001.htm>

From rmarchenko at openjdk.org  Thu Aug 14 12:34:16 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 14 Aug 2025 12:34:16 GMT
Subject: Integrated: 8365098: make/RunTests.gmk generates a wrong path to test
 artifacts on Alpine
In-Reply-To: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
References: <-fks-fcgy-zpsE8qbIjkriUHsKFB6Hwn-JMX6yOrYYM=.e8e1a8b8-e8cd-4c40-99bf-3db375074de8@github.com>
Message-ID: <m_j6jU9u57GirqFQ1jgBdLrmIhj_s0DfvBY6SNPZtEk=.d1cb0aba-139f-4ea5-8eba-99202cefd71a@github.com>

On Tue, 12 Aug 2025 10:51:06 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> This change fixes the test artifact path on Alpine as `'[_*1000]'` is not recognized as a correct pattern, at least on Alpine 3.11.
> 
> Without this fix, on Alpine the command `make test-prebuilt` generated paths like the following:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg]test]hotspot]jtreg]tier1]common
> 
> 
> Now it looks better:
> 
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_hotspot_jtreg_tier1_common
> 
> All checks (tier1) are passed.

This pull request has now been integrated.

Changeset: 41520998
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41520998aa8808452ee384b213b2a77c7bad668d
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8365098: make/RunTests.gmk generates a wrong path to test artifacts on Alpine

Reviewed-by: erikj, ihse

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

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

From erikj at openjdk.org  Thu Aug 14 12:57:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Aug 2025 12:57:12 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <Tac0Dr70VGxF7RQrYpvPLs6_1CuhX7pnom8ygwZDIC4=.78e6ae25-dcf1-442a-a95a-7551eed0a0f8@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120484397

From kbarrett at openjdk.org  Thu Aug 14 13:34:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 13:34:11 GMT
Subject: RFR: 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: <LNFzWcZpbSi-5zJoFW1NXx22oJIe-D0S_iLMCJnvqjs=.b0264468-8edb-41f6-bc59-d3836497b773@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.

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?

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

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

From stuefe at openjdk.org  Thu Aug 14 14:09:15 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 14 Aug 2025 14:09:15 GMT
Subject: RFR: 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: <wj-IfRyvE-NNK_gSoP8DsoDg7_2tjdHcSHbebWslAYU=.a98832b8-2e6b-4708-a403-37a7cbad17e6@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.

googletest uses C++ exceptions:


thomas at starfish:/shared/projects/openjdk/gtest/googletest-1.14.0$ ack 'throw [a-zA-Z]' | wc -l
68


And for C++ exception support we need `/EHsc`, `/EHs` or `/EHa`:
https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model?view=msvc-170


Standard C++ exception handling

Full compiler support for the Standard C++ exception handling model that safely unwinds stack objects requires /EHsc (recommended), /EHs, or /EHa.


So I don't think we should remove this compiler option.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3188586481

From mcimadamore at openjdk.org  Thu Aug 14 14:09:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Aug 2025 14:09:15 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <GuDQS-KY1JxK-inCuq2nUpzwHmlv2enJECfNpvtFqG8=.575786b8-3aed-425c-88ab-14a89f18f1ff@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120743925

From jwaters at openjdk.org  Thu Aug 14 14:47:11 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Aug 2025 14:47:11 GMT
Subject: RFR: 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: <6Y4P7EnP6dYOFK5VWdBLqmxTdFbL9kyOzAKX1f-okGc=.2bc15246-fd69-403a-98fe-92bb71d1c2f8@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.

I did take a brief look at the other Pull Request, but I still don't really understand this fully. Doesn't the gtest framework itself use C++ exceptions (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not used with gcc and clang when compiling gtest. It would be a bit odd if exceptions were disabled for only Windows (More accurately VC) and not any other platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3188719550

From jwaters at openjdk.org  Thu Aug 14 14:53:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Aug 2025 14:53:13 GMT
Subject: RFR: 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: <13UxlfWCmQ_-nlvGNZu5CdHy9KdnSkOK74OosLCuWDs=.281f68cb-9d07-436b-b472-1831ee917699@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.

make/hotspot/lib/CompileGtest.gmk line 65:

> 63:         unused-result zero-as-null-pointer-constant, \
> 64:     DISABLED_WARNINGS_clang := format-nonliteral undef unused-result, \
> 65:     DISABLED_WARNINGS_microsoft := 4530, \

I don't think this is a good idea. This doesn't fully force disable exceptions like -fno-exceptions does with gcc and clang, it can result in unexpected behaviour that causes hard to track bugs that will be difficult to solve if someone who isn't familiar with HotSpot rules introduces exceptions in gtest code (And perhaps in other cases even when exceptions aren't used too).

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

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

From ihse at openjdk.org  Thu Aug 14 14:53:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 14:53:12 GMT
Subject: RFR: 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: <ZKlru6B3vxwmkg5_vyBG3LHuIIZ06ItrmufIW-1WvIU=.35c89bb6-babe-487c-82fb-e31a95b9162d@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.

So we should not remove exceptions for libgtest. But for the special version of libjvm it still seem to make sense, right? Even if gtest uses exceptions internally in the framework, we should not compile our code differently. Or am I missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3188743250

From shade at openjdk.org  Thu Aug 14 14:57:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 14:57:14 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

bin/idea.sh line 128:

> 126: fi
> 127: 
> 128: # Git workstrees use a '.git' file rather than directory, so test both.

Suggestion:

# Git worktrees use a '.git' file rather than directory, so test both.


Right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26777#discussion_r2276874741

From ihse at openjdk.org  Thu Aug 14 15:10:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 15:10:14 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v2]
In-Reply-To: <_HedHy5F966CKB-J_xRbvt_gLfCk9BIlNvk5H5WpwHc=.2b9e787f-64be-4cb5-9ce4-5c6907ac4b28@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <_HedHy5F966CKB-J_xRbvt_gLfCk9BIlNvk5H5WpwHc=.2b9e787f-64be-4cb5-9ce4-5c6907ac4b28@github.com>
Message-ID: <o8oIeCS03gpF1LHLE9g3GtQMlZVaQuXxwk6sx1F45bQ=.4069b15d-e300-45f6-b82f-ead36bd04346@github.com>

On Wed, 13 Aug 2025 14:23:37 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent organizing imports

It's hard to say exactly if these changes are what is needed, but they look sane, and if you have verified that it works then I'm okay with it. 

Thanks for improving the IDE support!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26759#pullrequestreview-3120966144

From ihse at openjdk.org  Thu Aug 14 15:15:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 15:15:15 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <HWbdhM5b-mqbKf5BeUHYSD8XyZksjZmcMnmlBabx518=.b610199e-6fea-4d35-bf54-0c872578bf23@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

LGTM, if you fix the typo in the comment.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3120977831

From duke at openjdk.org  Thu Aug 14 15:15:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:15:17 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees
In-Reply-To: <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <jVfpvG27-Jqynp0FoWk-MJV6wtCj8dy8n5qkYy4KlPE=.d4306e1e-1f7e-4310-8db2-1d87c4c229b7@github.com>
Message-ID: <zXySn_76sMfkGuhGCwbLv9OemiCpiS7hGcy1knVe3NY=.8d9fc163-f859-444d-838c-20e6b8daebc7@github.com>

On Thu, 14 Aug 2025 14:54:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> bin/idea.sh line 128:
> 
>> 126: fi
>> 127: 
>> 128: # Git workstrees use a '.git' file rather than directory, so test both.
> 
> Suggestion:
> 
> # Git worktrees use a '.git' file rather than directory, so test both.
> 
> 
> Right?

*doh* - thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26777#discussion_r2276919398

From duke at openjdk.org  Thu Aug 14 15:21:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 15:21:29 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26777/files
  - new: https://git.openjdk.org/jdk/pull/26777/files/582a0143..307574fa

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

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

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

From jlahoda at openjdk.org  Thu Aug 14 15:29:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Aug 2025 15:29:10 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension
In-Reply-To: <hWe0uDs4CA6Mt_RYQUr5seLcPKQLnqOHkhFuTzP54MY=.a7a7bf1d-8fef-469e-a2a5-c93e8e65976e@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <99y0kw0loER23cXnLl2k88BEVY7XorBViF6SGADgNRY=.09ee46af-2a6b-4c95-8d26-f76117bb1f7f@github.com>
 <hWe0uDs4CA6Mt_RYQUr5seLcPKQLnqOHkhFuTzP54MY=.a7a7bf1d-8fef-469e-a2a5-c93e8e65976e@github.com>
Message-ID: <N_xYh3ehDnJE7RCzap2w0_3QN9EKSfRTSpQoX2ylthY=.6b7d45e0-e4b0-4edd-a8cd-f6aac2febc7f@github.com>

On Wed, 13 Aug 2025 14:24:28 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> > I would suggest to drop: `"jdk.advanced.disable.nbjavac": true,`
> 
> Can you elaborate on the surprising results? When developing the JDK we will most probably use features not supported by the `nbjavac`.

In general, it can be anything. From relatively minor problems like not working code completion in some corner case, to a complete failure of the Java editor features.

When nbjavac is disabled, the javac in the JDK on which the extension runs needs to be "close enough" to the version of javac on which nbjavac is based (I believe it is currently ~JDK 24). And depending on the differences between the version against which the extension is built and the real javac in JDK, the there may be unobservable, minor or major negative effects.

If the runtime JDK is too old, there's a warning. But if it is newer, then it is expected the user knows what they are doing. And I am not sure if everyone using this task will know how to interpret potential failures, given they didn't knowingly select the option.

(It is true that JDK 24 and JDK 25 seem to be close enough, so that there are no major effects, and maybe not even minor effects. That may or may not be the case with any upcoming JDK 26 version.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26759#issuecomment-3188868986

From shade at openjdk.org  Thu Aug 14 15:45:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 15:45:14 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
Message-ID: <kbmyFXqCXWPWrLp2OpJIhLtq1lHPWz-bWPN_MbSzQGY=.f79d7433-64b6-4046-b9d5-577a1f720a86@github.com>

On Thu, 14 Aug 2025 15:21:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26777#pullrequestreview-3121091987

From duke at openjdk.org  Thu Aug 14 16:56:19 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 16:56:19 GMT
Subject: RFR: 8365048: idea.sh script does not correctly detect/handle git
 worktrees [v2]
In-Reply-To: <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
 <VWUDhGN2q83w8OlYqoiH86nS3KGIuG7iPgz4Ht3rQf4=.13e45635-1086-46ac-b139-3625dc861c29@github.com>
Message-ID: <POJ80NJokh7WpThYZr7VToQeK1vRj7edNGVdQdgUa4Q=.f8f99f10-e00e-4502-b2bb-a40c35fdc5a7@github.com>

On Thu, 14 Aug 2025 15:21:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
>> Tested locally in a worktree and normal repository. It produces:
>> 
>>  <component name="VcsDirectoryMappings">
>>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>>   </component>
>> 
>> in both cases, as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

@david-beaumont 
Your change (at version 307574fa815477b3efe05c231956f516b80d53b9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26777#issuecomment-3189176682

From duke at openjdk.org  Thu Aug 14 17:05:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 14 Aug 2025 17:05:19 GMT
Subject: Integrated: 8365048: idea.sh script does not correctly detect/handle
 git worktrees
In-Reply-To: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
References: <0uUPK262bGaFrjW9a9R8J2pA_3kGi4pA7Nnn9FLFZ8Y=.aa46d4a5-11dd-4322-a1fa-483413e95e83@github.com>
Message-ID: <D4aPGmEAcbSm5u004g_6yDHdAZ_NQfCHAfLfN07NuW8=.5f9a68b3-5519-4476-8919-da9c2b47f05d@github.com>

On Thu, 14 Aug 2025 11:19:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> Allows files or directories called .git to indicate likely use of Git for VCS in IntelliJ.
> Tested locally in a worktree and normal repository. It produces:
> 
>  <component name="VcsDirectoryMappings">
>     <mapping directory="$PROJECT_DIR$" vcs="Git" />
>     <mapping directory="$PROJECT_DIR$/open" vcs="Git" />
>   </component>
> 
> in both cases, as expected.

This pull request has now been integrated.

Changeset: ba231052
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba231052319676ece5105253b58efa4e906feab4
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8365048: idea.sh script does not correctly detect/handle git worktrees

Reviewed-by: shade, vyazici, erikj, mcimadamore, ihse

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

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

From lmesnik at openjdk.org  Thu Aug 14 17:57:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 17:57:47 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v4]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:

 - removed space
 - removed wrong commit.
 - renamed functions, removed incorrect comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/49c2a67d..360db5d9

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

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

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

From kbarrett at openjdk.org  Thu Aug 14 19:03:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 19:03:10 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <wj-IfRyvE-NNK_gSoP8DsoDg7_2tjdHcSHbebWslAYU=.a98832b8-2e6b-4708-a403-37a7cbad17e6@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <wj-IfRyvE-NNK_gSoP8DsoDg7_2tjdHcSHbebWslAYU=.a98832b8-2e6b-4708-a403-37a7cbad17e6@github.com>
Message-ID: <N9drPLtC96GAd8vFMMl9Jq-zJEPPMgYYkKtoxxY52dQ=.fbb0534b-3434-4e7f-9cfe-946c9d22e304@github.com>

On Thu, 14 Aug 2025 14:06:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> googletest uses C++ exceptions:
> 
> ```
> thomas at starfish:/shared/projects/openjdk/gtest/googletest-1.14.0$ ack 'throw [a-zA-Z]' | wc -l
> 68

That just says there is source code that could potentially use exceptions, depending on configuration.
It doesn't mean they are used if configured to be disabled.  After all, there's `GTEST_HAS_EXCEPTIONS`.
And spot-checking some of the uses of `throw`, they are appropriately protected by that macro.

So as long as the macro is set properly...

If not explicitly set, it gets auto-set to 1 for `defined(_MSC_VER) && defined(_CPPUNWIND)`
with a comment saying the latter is set iff exceptions are enabled. And that seems true according to
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
"_CPPUNWIND Defined as 1 if one or more of the [/GX (Enable Exception Handling)](https://learn.microsoft.com/en-us/cpp/build/reference/gx-enable-exception-handling?view=msvc-170), [/clr (Common Language Runtime Compilation)](https://learn.microsoft.com/en-us/cpp/build/reference/clr-common-language-runtime-compilation?view=msvc-170), or [/EH (Exception Handling Model)](https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model?view=msvc-170) compiler options are set. Otherwise, undefined."

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3189559033

From kbarrett at openjdk.org  Thu Aug 14 19:16:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 19:16:11 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <6Y4P7EnP6dYOFK5VWdBLqmxTdFbL9kyOzAKX1f-okGc=.2bc15246-fd69-403a-98fe-92bb71d1c2f8@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <6Y4P7EnP6dYOFK5VWdBLqmxTdFbL9kyOzAKX1f-okGc=.2bc15246-fd69-403a-98fe-92bb71d1c2f8@github.com>
Message-ID: <GVkRseKVy7P9dPde5Rc2VHSDzu64hnRoZUMfHiz9UG4=.2c5559bf-b89f-4d0a-bd0a-ba20b8e9e540@github.com>

On Thu, 14 Aug 2025 14:44:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I did take a brief look at the other Pull Request, but I still don't really understand this fully. Doesn't the gtest framework itself use C++ exceptions (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not used with gcc and clang when compiling gtest. It would be a bit odd if exceptions were disabled for only Windows (More accurately VC) and not any other platform.

But `-fno-exceptions` *is* used for gcc (and probably for clang, though I've not checked). Verified by examination
of ".o.cmdline" files for both libgtest and the HotSpot gtests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3189591625

From kbarrett at openjdk.org  Thu Aug 14 19:16:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 19:16:12 GMT
Subject: RFR: 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: <0ZkEvZU21ZoNvU4yLgG-__yzcQu9kvlHmKBWWAczTKs=.f439c395-de47-423b-af9d-0f999e7d7825@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.

> But `-fno-exceptions` _is_ used for gcc (and probably for clang, though I've not checked). Verified by examination of ".o.cmdline" files for both libgtest and the HotSpot gtests.

Oh, and once again, thank you thank you thank you for the ".o.cmdline" files!

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3189596413

From kbarrett at openjdk.org  Thu Aug 14 19:27:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 19:27:11 GMT
Subject: RFR: 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: <uW_zYtDvWQKy0S3T5cB4sX-6WD3h71MWTrIDM-8fCdo=.444b3e16-5385-4840-aa88-23e231ee0626@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.

My guess is that MSVC C4530 needs to be disabled when building libgtest even
when we're not enabling exceptions for the same reason that I expected that
warning from our jfr/test_networkUtilization.cpp.

That jfr test includes `<vector>`, and vector::at throws, and that apparently
isn't protected by anything that knows about exceptions being disabled. (At
least, that's the problem I ran into a while ago.) So even if it's never
called, it still triggers the warning.

googletest also includes `<vector>` in a bunch of places, so I'd expect the same
issue there. Again, warnings even though that code is never called.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3189625063

From vyazici at openjdk.org  Thu Aug 14 19:32:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 14 Aug 2025 19:32:29 GMT
Subject: RFR: 8365244: Some test control variables are undocumented in
 doc/testing.md
Message-ID: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>

Synchronize `make/RunTests.gmk` keyword variables with `doc/testing.{md,html}`.

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

Commit messages:
 - Synchronize `make/RunTests.gmk` keyword variables with `doc/testing.{md,html}`

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

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

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 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:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From erikj at openjdk.org  Thu Aug 14 19:41:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Aug 2025 19:41:11 GMT
Subject: RFR: 8365244: Some test control variables are undocumented in
 doc/testing.md
In-Reply-To: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>
References: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>
Message-ID: <5uNZtKOqPnenKtj5rY5JdCmHdBMQ--gEFXf4sSVK8Zc=.3fa312cb-c8f2-42c2-b08b-d0916c0dafa3@github.com>

On Thu, 14 Aug 2025 19:26:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Synchronize `make/RunTests.gmk` keyword variables with `doc/testing.{md,html}`.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26789#pullrequestreview-3121900093

From lmesnik at openjdk.org  Thu Aug 14 19:44:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 19:44:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/360db5d9..d45c0701

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

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

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

From lmesnik at openjdk.org  Thu Aug 14 19:44:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Aug 2025 19:44:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v4]
In-Reply-To: <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <p87dbEDMlfYDTLMYTLnZt_zAnBU-ced1UXe74cj8JKs=.6c12e32f-6fe1-432a-8987-0adab8debde4@github.com>
Message-ID: <DBWB8LCZreAsAVGXvbuBbO8_K0UL_dZv-48sU8aFLHM=.20f0478f-bb61-46b1-b2c3-b81800b44839@github.com>

On Thu, 14 Aug 2025 17:57:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - removed space
>  - removed wrong commit.
>  - renamed functions, removed incorrect comments

Sorry, I just forgot to "apply" your comments, thanks for reminding!

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3189671622

From erikj at openjdk.org  Thu Aug 14 19:52:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Aug 2025 19:52:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
Message-ID: <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>

On Thu, 14 Aug 2025 19:44:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - Update test/lib/jdk/test/lib/jvmti/libJvmtiStressAgent.cpp
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

Makefile changes look good now.

I think this new option should be documented in testing.md/html.

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3121925674

From ihse at openjdk.org  Thu Aug 14 21:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 21:18:13 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
 <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
Message-ID: <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>

On Thu, 14 Aug 2025 19:49:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this new option should be documented in testing.md/html.

Yes, I agree. I tried to ask for this above. @lmesnik When you have updated the markdown file, run `make update-build-docs` to generate the html version.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3189894607

From kbarrett at openjdk.org  Thu Aug 14 22:23:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 22:23:10 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <uW_zYtDvWQKy0S3T5cB4sX-6WD3h71MWTrIDM-8fCdo=.444b3e16-5385-4840-aa88-23e231ee0626@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <uW_zYtDvWQKy0S3T5cB4sX-6WD3h71MWTrIDM-8fCdo=.444b3e16-5385-4840-aa88-23e231ee0626@github.com>
Message-ID: <lK8vELyDi6H33836nQowOVFbM-b7sUrdVzX5gFumNr8=.9eaef961-fef1-4ec9-9fdd-e033e8456fb2@github.com>

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

> My guess is that MSVC C4530 needs to be disabled when building libgtest even when we're not enabling exceptions for the same reason that I expected that warning from our jfr/test_networkUtilization.cpp.
> 
> That jfr test includes `<vector>`, and vector::at throws, and that apparently isn't protected by anything that knows about exceptions being disabled. (At least, that's the problem I ran into a while ago.) So even if it's never called, it still triggers the warning.
> 
> googletest also includes `<vector>` in a bunch of places, so I'd expect the same issue there. Again, warnings even though that code is never called.

Not `<vector>`, it's `<ostream>` or one of those: `basic_ostream<...>::operator<<(double)` may throw. Didn't see
any warnings from `<vector>` so that one may have been fixed, but still, it looks like the MS stdlib triggers warnings
when building with exceptions disabled.

So assuming it passes testing, this change seems fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3190020874

From kbarrett at openjdk.org  Thu Aug 14 22:23:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 14 Aug 2025 22:23:10 GMT
Subject: RFR: 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: <Lgk7PTvMJTgyCauNSmHQho1vuxDr9sh863VzpISYwwQ=.4ebe700f-4f5b-4273-8b8a-155d8b8f3c71@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.

Assuming no testing issues are encountered, this looks good to me.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26721#pullrequestreview-3122256650

From duke at openjdk.org  Fri Aug 15 00:06:28 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 15 Aug 2025 00:06:28 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows aarch64
Message-ID: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>

[ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.

The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

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

Commit messages:
 - Remove -Ta flag
 - Use armasm64.exe as the assembler for Windows aarch64

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

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

From lmesnik at openjdk.org  Fri Aug 15 04:33:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 04:33:59 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  add documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/d45c0701..514ed252

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

  Stats: 17 lines in 3 files changed: 13 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26360/head:pull/26360

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

From lmesnik at openjdk.org  Fri Aug 15 04:37:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 04:37:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <3Wv7WQnb0uRdX37iZ3RDXljs6cncyI8b6mTujVfp0A4=.5859b0a5-0dac-4eaa-831e-89c420393153@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Sorry, I just didn't have time today. I updated .md and regenerated .html using `make update-build-docs` command.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3190585133

From stuefe at openjdk.org  Fri Aug 15 05:40:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 05:40:10 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <6Y4P7EnP6dYOFK5VWdBLqmxTdFbL9kyOzAKX1f-okGc=.2bc15246-fd69-403a-98fe-92bb71d1c2f8@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <6Y4P7EnP6dYOFK5VWdBLqmxTdFbL9kyOzAKX1f-okGc=.2bc15246-fd69-403a-98fe-92bb71d1c2f8@github.com>
Message-ID: <6ohN4d_NgrNsfHXC4IcnfzBIcq1NFf0maLzNFgQaXcI=.b7b5337b-4371-4f98-9a37-bd8e1156b6bf@github.com>

On Thu, 14 Aug 2025 14:44:21 GMT, Julian Waters <jwaters 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.
>
> I did take a brief look at the other Pull Request, but I still don't really understand this fully. Doesn't the gtest framework itself use C++ exceptions (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not used with gcc and clang when compiling gtest. It would be a bit odd if exceptions were disabled for only Windows (More accurately VC) and not any other platform.

I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?

What is the motivation for this change? What do we gain by switching the feature off? This switch only applies to the gtest compilation units, right, not to the libjvm? Don't we link googletest and libjvm statically? Are exceptions thrown from header files that are compiled as part of the gtest libjvm?

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3190668595

From mhaessig at openjdk.org  Fri Aug 15 06:36:46 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 15 Aug 2025 06:36:46 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v3]
In-Reply-To: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
Message-ID: <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>

> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Enable nbjavac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26759/files
  - new: https://git.openjdk.org/jdk/pull/26759/files/277a590d..bfa9d40c

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

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

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

From mhaessig at openjdk.org  Fri Aug 15 06:36:47 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 15 Aug 2025 06:36:47 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v2]
In-Reply-To: <_HedHy5F966CKB-J_xRbvt_gLfCk9BIlNvk5H5WpwHc=.2b9e787f-64be-4cb5-9ce4-5c6907ac4b28@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <_HedHy5F966CKB-J_xRbvt_gLfCk9BIlNvk5H5WpwHc=.2b9e787f-64be-4cb5-9ce4-5c6907ac4b28@github.com>
Message-ID: <YW94gcHswvInzeim9t8X7hMB4_9YR0yjyylo5b9QUJc=.eb1d8dd5-7fa5-4b28-b9cc-42862d79ce9f@github.com>

On Wed, 13 Aug 2025 14:23:37 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent organizing imports

I was not aware that it had to be "close" to nbjavac. Then enabling nbjavac makes much more sense. Thank you for explaining this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26759#issuecomment-3190762251

From jwaters at openjdk.org  Fri Aug 15 06:48:10 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Aug 2025 06:48:10 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <0ZkEvZU21ZoNvU4yLgG-__yzcQu9kvlHmKBWWAczTKs=.f439c395-de47-423b-af9d-0f999e7d7825@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <0ZkEvZU21ZoNvU4yLgG-__yzcQu9kvlHmKBWWAczTKs=.f439c395-de47-423b-af9d-0f999e7d7825@github.com>
Message-ID: <7oSTN3OqyJEONNvAXOfbMmtW_yNV5YjZzTnAnMrn468=.d4f4ec82-de95-43f2-82b1-389356f6e5e0@github.com>

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

> But `-fno-exceptions` _is_ used for gcc

-fno-exceptions to my knowledge is only set in TOOLCHAIN_CFLAGS_JVM and for adlc compiled for Linux. That must mean gtest uses the same flags that the regular JVM does. I was not aware of that, so that would make my previous statement incorrect.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3190779189

From jwaters at openjdk.org  Fri Aug 15 06:55:10 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Aug 2025 06:55:10 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64
In-Reply-To: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
Message-ID: <4oh3OERh33-hz6XeVuQBkiLmm_EQxll27TceRh3Ml3s=.e4829e72-ad0b-4726-ba3e-30d7b1f4a53b@github.com>

On Thu, 14 Aug 2025 23:59:23 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
> 
> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

I'd prefer if -Ta could be kept somehow but there doesn't seem to be a clean way to do that, so this gets a +1 from me anyway

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26791#pullrequestreview-3123104105

From sspitsyn at openjdk.org  Fri Aug 15 07:03:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Aug 2025 07:03:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <4l03LqVrTEjF0hwX9gcoaopc4ADypXFmUCNYFht2Fp8=.3d2946a8-02e6-40fb-b434-59c394cc187f@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Thank you for the updates in the stress agent `.cpp` file!
This looks okay to me modulo potential doc update.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123114291

From ihse at openjdk.org  Fri Aug 15 08:41:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:41:16 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <mOOh-94SQTg7Wv_BuNch9Nww8heX1c0fisU3YtDFHr8=.cd9ad424-80b3-42d5-8df7-d2701d5bc096@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

LGTM now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123261422

From ihse at openjdk.org  Fri Aug 15 08:43:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:43:12 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v3]
In-Reply-To: <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
Message-ID: <j5XBrkYzCBwq3WNEOhLRsgF_GVGLg0n4kjy79gTQCZk=.e65501eb-5fac-46e2-9b70-73c4dba9adc1@github.com>

On Fri, 15 Aug 2025 06:36:46 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable nbjavac

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26759#pullrequestreview-3123262333

From jlahoda at openjdk.org  Fri Aug 15 08:43:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Aug 2025 08:43:12 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v3]
In-Reply-To: <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
Message-ID: <vJq6c8e6d5KBqyqwR_vgs-vF0K8aNxSnDk1_oOTk_9s=.8bc1d74b-831a-4227-adbd-05899e67ac5d@github.com>

On Fri, 15 Aug 2025 06:36:46 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable nbjavac

Thanks, @mhaessig!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26759#pullrequestreview-3123264543

From ihse at openjdk.org  Fri Aug 15 08:46:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:46:21 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <7oSTN3OqyJEONNvAXOfbMmtW_yNV5YjZzTnAnMrn468=.d4f4ec82-de95-43f2-82b1-389356f6e5e0@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <0ZkEvZU21ZoNvU4yLgG-__yzcQu9kvlHmKBWWAczTKs=.f439c395-de47-423b-af9d-0f999e7d7825@github.com>
 <7oSTN3OqyJEONNvAXOfbMmtW_yNV5YjZzTnAnMrn468=.d4f4ec82-de95-43f2-82b1-389356f6e5e0@github.com>
Message-ID: <4vaqDlEWvl2uy5B-SzmofdUn6ggAODgRjw_nGwp-XDI=.9241ee6d-180f-478f-a1a5-ac4ead6baae6@github.com>

On Fri, 15 Aug 2025 06:45:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> But `-fno-exceptions` _is_ used for gcc (and probably for clang, though I've not checked). Verified by examination of ".o.cmdline" files for both libgtest and the HotSpot gtests.
>> 
>> Oh, and once again, thank you thank you thank you for the ".o.cmdline" files!
>
>> But `-fno-exceptions` _is_ used for gcc
> 
> -fno-exceptions to my knowledge is only set in TOOLCHAIN_CFLAGS_JVM and for adlc compiled for Linux. That must mean gtest uses the same flags that the regular JVM does. I was not aware of that, so that would make my previous statement incorrect.

> I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?

As Kim wrote, this seems to be about a bug in the compiler. If you include certain standard headers (`<ostream>`), the compiler will give this warning, regardless if you use any functions from the header or not, if you compile with exceptions disabled.

Our normal libjvm is compiled with exceptions disabled. It makes sense to run tests on a build that is as close as possible to the real thing, so we should compile libjvm for gtest with exceptions disabled, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3190969501

From ihse at openjdk.org  Fri Aug 15 08:48:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 08:48:14 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v6]
In-Reply-To: <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <ocdJwOYnCdEYdjHhjdrqRtrDzUDLks_Lc45rrwDIqA0=.58fee4d6-4435-4cb5-a561-f51b854883ee@github.com>
Message-ID: <QCO91hIQ9kjsa4Rz0UWogznMEJY294fuUE841MfK4nM=.09050211-f06e-48a0-90ba-c4fbde1b9aaa@github.com>

On Fri, 15 Aug 2025 04:33:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documentation

Actually, GHA testing fails with an error in libJvmtiStressAgent.cpp. Please investigate.

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

Changes requested by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3123276665

From mhaessig at openjdk.org  Fri Aug 15 08:58:17 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 15 Aug 2025 08:58:17 GMT
Subject: Integrated: 8365491: VSCode IDE: add basic configuration for the
 Oracle Java extension
In-Reply-To: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
Message-ID: <ZCkbv_VPyTSJkOhL-F-xi0oEnv4TSZsBxugYu2v8Kts=.6f47293a-8a10-49cf-899a-44c4cd44b45d@github.com>

On Wed, 13 Aug 2025 13:22:21 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.

This pull request has now been integrated.

Changeset: fa2eb616
Author:    Manuel H?ssig <mhaessig at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa2eb616482250dff6a3b667798aec37114005a9
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8365491: VSCode IDE: add basic configuration for the Oracle Java extension

Reviewed-by: ihse, jlahoda

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

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

From mhaessig at openjdk.org  Fri Aug 15 08:58:16 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 15 Aug 2025 08:58:16 GMT
Subject: RFR: 8365491: VSCode IDE: add basic configuration for the Oracle
 Java extension [v3]
In-Reply-To: <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
References: <tQ_uND-qkm8v4N4x2ZYASbfOmsEwcawvdhw78EiQ1jI=.891cb663-5757-4828-97ea-fbe14e79154d@github.com>
 <XrSXRzClb6lL8MvGrQ6CIR20X135AeSr28SVJ5vByJk=.247042cd-3c6c-4c69-b1e2-921c75ffe2de@github.com>
Message-ID: <lbJu-zONRpOwUxAroRs_ekxoBNJiCr_J7E-bREK-PrY=.10b6e5ab-cfb4-42b2-a3a7-b271ae993450@github.com>

On Fri, 15 Aug 2025 06:36:46 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> This PR adds a basic configuration for the [Oracle Java VSCode extension](https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java) to the `vscode-project-*` targets.
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable nbjavac

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26759#issuecomment-3190987969

From vyazici at openjdk.org  Fri Aug 15 10:37:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 10:37:10 GMT
Subject: RFR: 8365244: Some test control variables are undocumented in
 doc/testing.md
In-Reply-To: <5uNZtKOqPnenKtj5rY5JdCmHdBMQ--gEFXf4sSVK8Zc=.3fa312cb-c8f2-42c2-b08b-d0916c0dafa3@github.com>
References: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>
 <5uNZtKOqPnenKtj5rY5JdCmHdBMQ--gEFXf4sSVK8Zc=.3fa312cb-c8f2-42c2-b08b-d0916c0dafa3@github.com>
Message-ID: <w1_sQorLfjtbHQYq12GY9KmVdNSEXJbnu5o-68jjcYk=.191e8976-4d33-4ee6-87db-3075347b8eb7@github.com>

On Thu, 14 Aug 2025 19:38:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Synchronize `make/RunTests.gmk` keyword variables with `doc/testing.{md,html}`.
>
> Marked as reviewed by erikj (Reviewer).

@erikj79, thanks for the review. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26789#issuecomment-3191215905

From vyazici at openjdk.org  Fri Aug 15 10:40:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 10:40:15 GMT
Subject: Integrated: 8365244: Some test control variables are undocumented in
 doc/testing.md
In-Reply-To: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>
References: <-jmAeutoR_uvUA8g482hM530yYF_hYjHuWqhSj__h0M=.59205b71-dba1-46ca-be79-eb7bfcf043a3@github.com>
Message-ID: <jYnBI1OqsMC1JCm0LJSVH2Xp2nXjS9I3AKB1of3LJG0=.bf013556-e4fc-470c-8209-33ba6e4ad76f@github.com>

On Thu, 14 Aug 2025 19:26:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Synchronize `make/RunTests.gmk` keyword variables with `doc/testing.{md,html}`.

This pull request has now been integrated.

Changeset: 059b49b9
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/059b49b9551ad52f211613a3da2ac0a79deb5ed4
Stats:     32 lines in 2 files changed: 25 ins; 2 del; 5 mod

8365244: Some test control variables are undocumented in doc/testing.md

Reviewed-by: erikj

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

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

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@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:

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From duke at openjdk.org  Fri Aug 15 13:38:16 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 15 Aug 2025 13:38:16 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <roJ4dlKIZmldgH1SLmn58wGPERh48P-p_JbUSW6nR1A=.9a7236ea-3079-481d-a7b2-897c7e755b65@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
 <roJ4dlKIZmldgH1SLmn58wGPERh48P-p_JbUSW6nR1A=.9a7236ea-3079-481d-a7b2-897c7e755b65@github.com>
Message-ID: <_mDI_WpB9sqgKfdByZVen_cmEklkavJHh8hEQ_6OwZE=.7593f277-3d0f-42bb-bf08-a1456adaf53e@github.com>

On Thu, 14 Aug 2025 09:27:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If I recall correctly the original approach was even simpler: I counted the number of #includes in the C++ source files, not in the dependency files of a particular build. Crude but effective, and left out discussions about differences between platforms and feature configurations. And then I had to do some adjustments for Windows where my approach of excluding inline files did not hold and caused a regression.

That was also the initial approach in this PR, I got the suggestion from the first comments I got here.

> But then again, this is basically an optimization problem (even if it is not about running code in the JVM, but about optimizing build speed) so there is no way around the mantra of measure, measure and measure again.

Yeah I see, I'll give it another shot next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3191518492

From stuefe at openjdk.org  Fri Aug 15 14:05:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 14:05:11 GMT
Subject: RFR: 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: <k8Qhhe3oJsVKj-aOrfPUFYlMt5GXPul_1XVir8aepQM=.f33e135d-6755-4ee5-bba6-d1da90f1a945@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.

Marked as reviewed by stuefe (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26721#pullrequestreview-3123934019

From stuefe at openjdk.org  Fri Aug 15 14:05:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 15 Aug 2025 14:05:12 GMT
Subject: RFR: 8365231: Don't build gtest with /EHsc
In-Reply-To: <7oSTN3OqyJEONNvAXOfbMmtW_yNV5YjZzTnAnMrn468=.d4f4ec82-de95-43f2-82b1-389356f6e5e0@github.com>
References: <VjwQ2Ual8_0aoG2jqzVMY451Z7Th9VhBMBi95_DME9o=.23979d20-e548-4aac-b312-55439dca5b19@github.com>
 <0ZkEvZU21ZoNvU4yLgG-__yzcQu9kvlHmKBWWAczTKs=.f439c395-de47-423b-af9d-0f999e7d7825@github.com>
 <7oSTN3OqyJEONNvAXOfbMmtW_yNV5YjZzTnAnMrn468=.d4f4ec82-de95-43f2-82b1-389356f6e5e0@github.com>
Message-ID: <b2z-4qArj6Th8xo_oHhwhLxzvdoPlUr1bz0tdA_PhCs=.ee7204d0-610f-4ddb-b648-9123c53e8095@github.com>

On Fri, 15 Aug 2025 06:45:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> But `-fno-exceptions` _is_ used for gcc (and probably for clang, though I've not checked). Verified by examination of ".o.cmdline" files for both libgtest and the HotSpot gtests.
>> 
>> Oh, and once again, thank you thank you thank you for the ".o.cmdline" files!
>
>> But `-fno-exceptions` _is_ used for gcc
> 
> -fno-exceptions to my knowledge is only set in TOOLCHAIN_CFLAGS_JVM and for adlc compiled for Linux. That must mean gtest uses the same flags that the regular JVM does. I was not aware of that, so that would make my previous statement incorrect.

> > I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?
> 
> As Kim wrote, this seems to be about a bug in the compiler. If you include certain standard headers (`<ostream>`), the compiler will give this warning, regardless if you use any functions from the header or not, if you compile with exceptions disabled.
> 
> Our normal libjvm is compiled with exceptions disabled. It makes sense to run tests on a build that is as close as possible to the real thing, so we should compile libjvm for gtest with exceptions disabled, too.

Okay, so we switch the risk of mismatched tests (since we are compiled with a different setting than the production JVM) with the risk of strange errors should we accidentally trigger C++ exceptions in the googletest framework or in system libraries used by it.

I guess I can see the logic. Okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/26721#issuecomment-3191577136

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

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

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

From fgao at openjdk.org  Fri Aug 15 14:18:57 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 15 Aug 2025 14:18:57 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

Fei Gao 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:

 - Add flag in debug builds and nothing in release builds
 - Merge branch 'master' into switch-pattern-to-zero
 - 8365312: __builtin_clear_padding not supported for variable length aggregates
   
   `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added
   recently to help detect uses of uninitialized memory. [2] Under
   this extension mode, `__builtin_clear_padding` is called to clear
   the padding bits in object representation. But the builtin function
   does not support variable length aggregates [3].
   
   `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is
   defined as an opaque sizeless type in ARM C Language Extensions
   (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type,
   it triggers the unsupported code path and results in build failures
   when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
   
   Switching the initialization mode with gcc-12 from `pattern` to `zero`
   avoids the use of this unsupported `__builtin_clear_padding` and
   resolves the issue.
   
   I did not encounter similar problems when building with Clang-16 [6].
   
   This patch changes the initialization mode from `pattern` to `zero`
   when compiling libsleef SVE component on Linux-AArch64 with gcc-12
   to fix the build failure and help avoid potential security issues
   related to uninitialized padding
   
   Testing (combined with https://github.com/openjdk/jdk/pull/26577):
   1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
   2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and
      NEON machines
   
   [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
   [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
   [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
   [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
   [5] https://bugs.openjdk.org/browse/JDK-8364185
   [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26755/files
  - new: https://git.openjdk.org/jdk/pull/26755/files/e8bfe2b5..242ba542

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

  Stats: 15102 lines in 428 files changed: 8123 ins; 5212 del; 1767 mod
  Patch: https://git.openjdk.org/jdk/pull/26755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26755/head:pull/26755

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

From fgao at openjdk.org  Fri Aug 15 14:18:58 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 15 Aug 2025 14:18:58 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <pGxh3nRjPoNhJ3zDN5xIBO-AGi_dVA3Ic27md_kiAkA=.f9208379-e8a8-4c2c-b162-bcb3bb977c4b@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

> tier1, tier2, tier3 testing of this and #26577 completed without any related failures. Once the PR is approved (I see Kim has suggested some changes), I will run a final round of tests.

Thanks a lot for your help! @jaikiran

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3191608837

From fgao at openjdk.org  Fri Aug 15 14:18:58 2025
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 15 Aug 2025 14:18:58 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <9e3JH2ZJGP1wW1i5pA56IHk2MKaOu-FTFv_xZrUlFu4=.5a879e52-753d-4b0d-b806-a9ae2de6104d@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>
 <9e3JH2ZJGP1wW1i5pA56IHk2MKaOu-FTFv_xZrUlFu4=.5a879e52-753d-4b0d-b806-a9ae2de6104d@github.com>
Message-ID: <2IKFVSuqBXDLfk2E4YprOy3liO5_tuVTrA81m_osJmY=.ef604d55-6b75-4bbd-a451-dcb7a839609b@github.com>

On Thu, 14 Aug 2025 09:43:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 960:
>> 
>>> 958:             # avoids the use of unsupported `__builtin_clear_padding` for variable
>>> 959:             # length aggregates
>>> 960:             if test "x$TOOLCHAIN_TYPE" = xgcc ; then
>> 
>> We only add `-ftrival-auto-var-init=pattern` when "x$DEBUG_LEVEL" != "xrelease", e.g. only in
>> debug builds.  I think we should only add the `=zero` flag in debug builds and nothing in release
>> builds here too.
>
> I agree. Make sure to use the same test (DEBUG_LEVEL != release) to catch both fast and slow debug builds.

That does make sense. Updated in the new commit. Thanks! @magicus @kimbarrett

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26755#discussion_r2279071503

From erikj at openjdk.org  Fri Aug 15 14:30:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 14:30:10 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64
In-Reply-To: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
Message-ID: <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>

On Thu, 14 Aug 2025 23:59:23 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
> 
> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

make/autoconf/toolchain.m4 line 668:

> 666:         # otherwise, the assembler is "ml.exe"
> 667:         UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml)
> 668:       fi

I think this would be more readable as an `elif` with all the cases on the same level rather than nesting the second if/else inside the else block.

make/common/native/CompileFile.gmk line 239:

> 237: 	    $$(call ExecuteWithLog, $$@, $$(call MakeCommandRelative, \
> 238: 	        $$($1_COMPILER) $$($1_FLAGS) \
> 239: 	        $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE))) \

Have you verified that removing `-Ta` works for the x86 assembler?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2279092729
PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2279090903

From lmesnik at openjdk.org  Fri Aug 15 15:05:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 15:05:02 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

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

  initialization of array fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26360/files
  - new: https://git.openjdk.org/jdk/pull/26360/files/514ed252..0dc79e03

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

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

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

From duke at openjdk.org  Fri Aug 15 15:46:58 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 15 Aug 2025 15:46:58 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
Message-ID: <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>

> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
> 
> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

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

  Reduce nesting levels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26791/files
  - new: https://git.openjdk.org/jdk/pull/26791/files/164bef5f..2ae8f30c

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

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

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

From duke at openjdk.org  Fri Aug 15 15:46:59 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 15 Aug 2025 15:46:59 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>
Message-ID: <cszVLDnXYlAGWyA2mSy9kwmzppRLPwYEZnbpeFY9tRo=.258da448-4d7a-4666-81b6-567569a5b3d2@github.com>

On Fri, 15 Aug 2025 14:26:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Have you verified that removing `-Ta` works for the x86 assembler?

Yes, both of these command lines work:


; "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x86\ml.exe" -nologo -c -Fo test_x86_assembler.obj -Ta test_x86_assembler.S
; "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x86\ml.exe" -nologo -c -Fo test_x86_assembler.obj test_x86_assembler.S

TEST_SEG   SEGMENT

   mov eax, ecx

TEST_SEG   ENDS

END

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2279328852

From jwaters at openjdk.org  Fri Aug 15 16:45:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Aug 2025 16:45:13 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
Message-ID: <gx87MPTv-jZ5Pz4rI88eXLFOI4MxTa790iywjKMSccE=.d9da2a0e-e9ef-47d2-a2b8-53fd30f8a710@github.com>

On Fri, 15 Aug 2025 15:46:58 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
>> 
>> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce nesting levels

This is still ok with me

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26791#pullrequestreview-3124502265

From jwaters at openjdk.org  Fri Aug 15 16:45:14 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Aug 2025 16:45:14 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <cszVLDnXYlAGWyA2mSy9kwmzppRLPwYEZnbpeFY9tRo=.258da448-4d7a-4666-81b6-567569a5b3d2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>
 <cszVLDnXYlAGWyA2mSy9kwmzppRLPwYEZnbpeFY9tRo=.258da448-4d7a-4666-81b6-567569a5b3d2@github.com>
Message-ID: <MBEQVClQj8p-Lt5XPrFBDN0-pT1yrad7vO3d8MmuYiI=.fcf48bd3-7dc4-490d-9413-ec39eb691488@github.com>

On Fri, 15 Aug 2025 15:43:45 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> make/common/native/CompileFile.gmk line 239:
>> 
>>> 237: 	    $$(call ExecuteWithLog, $$@, $$(call MakeCommandRelative, \
>>> 238: 	        $$($1_COMPILER) $$($1_FLAGS) \
>>> 239: 	        $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE))) \
>> 
>> Have you verified that removing `-Ta` works for the x86 assembler?
>
>> Have you verified that removing `-Ta` works for the x86 assembler?
> 
> Yes, both of these command lines work:
> 
> 
> ; "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x86\ml.exe" -nologo -c -Fo test_x86_assembler.obj -Ta test_x86_assembler.S
> ; "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x86\ml.exe" -nologo -c -Fo test_x86_assembler.obj test_x86_assembler.S
> 
> TEST_SEG   SEGMENT
> 
>    mov eax, ecx
> 
> TEST_SEG   ENDS
> 
> END

I wonder why we still have the assembler for 32 bit, as the JDK no longer supports 32 bit Windows ever since Magnus nuked it from the codebase

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2279458499

From erikj at openjdk.org  Fri Aug 15 16:57:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 16:57:15 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <z7cQSOF6vhL_tde4GXXjKzZWygdmCvZVwKMcBW75pdQ=.f9ebe983-39ae-4a8a-b4b8-cd17167482b3@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3124547850

From erikj at openjdk.org  Fri Aug 15 16:59:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 16:59:14 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
Message-ID: <Mabqe1CB2oiDZkLo1altCthmFJgIa3DwTcDqT5gsAcQ=.3707a92e-cd28-4599-8949-f668b442113d@github.com>

On Fri, 15 Aug 2025 15:46:58 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
>> 
>> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce nesting levels

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26791#pullrequestreview-3124553719

From duke at openjdk.org  Fri Aug 15 17:34:13 2025
From: duke at openjdk.org (duke)
Date: Fri, 15 Aug 2025 17:34:13 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
Message-ID: <rhh1noh93qs7SrTFnVhZD1kkcAWXAhNCLEjzP_GCNTQ=.1191f773-d0f6-4ded-a399-3cacc74cdfe4@github.com>

On Fri, 15 Aug 2025 15:46:58 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
>> 
>> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce nesting levels

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26791#issuecomment-3192263733

From lmesnik at openjdk.org  Fri Aug 15 17:36:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 17:36:12 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <D6kWOak-Gr4XrgnBxrT7fpjHU8DXSSvJROqP-fpKC00=.1355a4d5-120d-4ded-8cbd-341adc1e0d9d@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

Thanks! I fixed cpp issue. Interesting that our builds worked before. Re-run tier1 to verify builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3192267556

From ihse at openjdk.org  Fri Aug 15 22:39:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 22:39:11 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v7]
In-Reply-To: <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <2ItmicHVzaK9RPwBO02peS25kLchdlRv_HvkYA7_qG4=.cb600cc0-ed51-426c-b093-c922e1a3e4d9@github.com>
Message-ID: <OCwmQQK3q00bdUA2zbyCNQdwjkZ2OtuqWbH41uRgiMg=.f6e44820-d9a7-42ab-9f36-3e65d2f7cef6@github.com>

On Fri, 15 Aug 2025 15:05:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix added JVMTI stress testing mode.
>> 
>> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
>> 
>> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
>> 
>> The agent has 2 modes now:
>>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
>> 
>> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
>> Note, that flagless tests are excluded automatically and not executed in this mode.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initialization of array fixed

LGTMN.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26360#pullrequestreview-3125301189

From ihse at openjdk.org  Fri Aug 15 22:40:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Aug 2025 22:40:13 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
Message-ID: <lXgaqqmj6wb2ehu156U41menNTw_pbKyncl49Rpf2Jc=.17d14d1b-54d5-480c-a8de-ef1228ce25c3@github.com>

On Fri, 15 Aug 2025 14:18:57 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> Fei Gao 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:
> 
>  - Add flag in debug builds and nothing in release builds
>  - Merge branch 'master' into switch-pattern-to-zero
>  - 8365312: __builtin_clear_padding not supported for variable length aggregates
>    
>    `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added
>    recently to help detect uses of uninitialized memory. [2] Under
>    this extension mode, `__builtin_clear_padding` is called to clear
>    the padding bits in object representation. But the builtin function
>    does not support variable length aggregates [3].
>    
>    `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is
>    defined as an opaque sizeless type in ARM C Language Extensions
>    (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type,
>    it triggers the unsupported code path and results in build failures
>    when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>    
>    Switching the initialization mode with gcc-12 from `pattern` to `zero`
>    avoids the use of this unsupported `__builtin_clear_padding` and
>    resolves the issue.
>    
>    I did not encounter similar problems when building with Clang-16 [6].
>    
>    This patch changes the initialization mode from `pattern` to `zero`
>    when compiling libsleef SVE component on Linux-AArch64 with gcc-12
>    to fix the build failure and help avoid potential security issues
>    related to uninitialized padding
>    
>    Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>    1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>    2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and
>       NEON machines
>    
>    [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>    [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>    [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>    [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>    [5] https://bugs.openjdk.org/browse/JDK-8364185
>    [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

LGTMN

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26755#pullrequestreview-3125301907

From lmesnik at openjdk.org  Fri Aug 15 22:48:20 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 22:48:20 GMT
Subject: RFR: 8364973: Add JVMTI stress testing mode [v5]
In-Reply-To: <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
 <VadFOl-c3YXK0gtkVitGF-kFQpux2QKfnhYM40sgUn4=.be835ba2-090e-44dd-8b45-a2c18caf9456@github.com>
 <u4MMn-V6jCc-EnD3MhNSni375i5aigEojiLj1Mcoiis=.dca4effa-501d-4933-a6ff-ab29c740ed64@github.com>
 <qlNebN3xJFHgfbDPIzK702OqMlpmqtdq6vzfY_5I6hQ=.4c0b19cb-5cfe-4d17-8f57-fbd4749d6969@github.com>
Message-ID: <glVYs39XO2XVAVi8XwZfIwwtqjkM__LWVUlNPYgle6k=.32b9a0e7-271d-45c9-8dab-5924a68218c5@github.com>

On Thu, 14 Aug 2025 21:15:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Makefile changes look good now.
>> 
>> I think this new option should be documented in testing.md/html.
>
>> I think this new option should be documented in testing.md/html.
> 
> Yes, I agree. I tried to ask for this above. @lmesnik When you have updated the markdown file, run `make update-build-docs` to generate the html version.

@magicus , @erikj79,  @sspitsyn Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26360#issuecomment-3192942142

From lmesnik at openjdk.org  Fri Aug 15 22:48:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Aug 2025 22:48:22 GMT
Subject: Integrated: 8364973: Add JVMTI stress testing mode
In-Reply-To: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
References: <TnOJud_pjA3hJN0tgjdNFgW4RCdy8c-HcwtLyQ3APGM=.f3bebcf0-2acb-43bc-a7ba-de3cac0cf721@github.com>
Message-ID: <454Ns3j_zbqBf1aNJiYQyTBmat468MpZ30TwMz3oDQY=.1d612ec3-8190-4618-b76a-f012601244c8@github.com>

On Thu, 17 Jul 2025 02:39:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix added JVMTI stress testing mode.
> 
> This mode enables stress agent that could be executed with jtreg test and help to ensure that jvmti functionality doesn't break the other JVM/JDK functionality.
> 
> I filed few issues and more are coming. I want to push the agent so it is possible to provide reproduces for problems uncovered by this agent.
> 
> The agent has 2 modes now:
>  - regular that is compatible with most of tests including other jvmti, jdi and jdb tests
>  - debugger, that additionally test some function requiring  solo capabilities and not compatible with debugger and some jvmti  tests 
> 
> The tests incompatible wiht agent (IR, CDS) and some individual tests from tier1 are excluded. There are not plans to support stable execution of all tests with agent right now. However it provokes some crashes worth to be used for exploratory testing.
> Note, that flagless tests are excluded automatically and not executed in this mode.

This pull request has now been integrated.

Changeset: a70521c6
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a70521c62e0841895d71cce2c872bd12f1183e33
Stats:     1199 lines in 10 files changed: 1192 ins; 3 del; 4 mod

8364973: Add JVMTI stress testing mode

Reviewed-by: erikj, ihse, sspitsyn

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

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

From kbarrett at openjdk.org  Fri Aug 15 23:43:13 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Aug 2025 23:43:13 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <2IKFVSuqBXDLfk2E4YprOy3liO5_tuVTrA81m_osJmY=.ef604d55-6b75-4bbd-a451-dcb7a839609b@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>
 <9e3JH2ZJGP1wW1i5pA56IHk2MKaOu-FTFv_xZrUlFu4=.5a879e52-753d-4b0d-b806-a9ae2de6104d@github.com>
 <2IKFVSuqBXDLfk2E4YprOy3liO5_tuVTrA81m_osJmY=.ef604d55-6b75-4bbd-a451-dcb7a839609b@github.com>
Message-ID: <10g0iPiQojYL5nY_Ifr8Dq-GfTdwSGwknNC-3vQsPPs=.1d1b012a-c4cf-4b83-8b91-b48a2192a6da@github.com>

On Fri, 15 Aug 2025 14:14:41 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> I agree. Make sure to use the same test (DEBUG_LEVEL != release) to catch both fast and slow debug builds.
>
> That does make sense. Updated in the new commit. Thanks! @magicus @kimbarrett

I think using `DEBUG_LEVEL != release` isn't right for either of these places, since it means we're adding
the option for "optimize" builds. But doing so here is consistent. I will file a separate issue to address the
"optimize" build case"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26755#discussion_r2280030665

From kbarrett at openjdk.org  Fri Aug 15 23:43:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Aug 2025 23:43:12 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
Message-ID: <u7JXVSnYMP3Vz5qYjgeIS4YlW7q3F_jrhlNlOsyM13M=.8eac197f-fea4-4361-80aa-31419a2798a1@github.com>

On Fri, 15 Aug 2025 14:18:57 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> Fei Gao 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:
> 
>  - Add flag in debug builds and nothing in release builds
>  - Merge branch 'master' into switch-pattern-to-zero
>  - 8365312: __builtin_clear_padding not supported for variable length aggregates
>    
>    `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added
>    recently to help detect uses of uninitialized memory. [2] Under
>    this extension mode, `__builtin_clear_padding` is called to clear
>    the padding bits in object representation. But the builtin function
>    does not support variable length aggregates [3].
>    
>    `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is
>    defined as an opaque sizeless type in ARM C Language Extensions
>    (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type,
>    it triggers the unsupported code path and results in build failures
>    when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>    
>    Switching the initialization mode with gcc-12 from `pattern` to `zero`
>    avoids the use of this unsupported `__builtin_clear_padding` and
>    resolves the issue.
>    
>    I did not encounter similar problems when building with Clang-16 [6].
>    
>    This patch changes the initialization mode from `pattern` to `zero`
>    when compiling libsleef SVE component on Linux-AArch64 with gcc-12
>    to fix the build failure and help avoid potential security issues
>    related to uninitialized padding
>    
>    Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>    1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>    2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and
>       NEON machines
>    
>    [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>    [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>    [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>    [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>    [5] https://bugs.openjdk.org/browse/JDK-8364185
>    [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26755#pullrequestreview-3125356783

From kbarrett at openjdk.org  Sat Aug 16 00:04:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 16 Aug 2025 00:04:10 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <10g0iPiQojYL5nY_Ifr8Dq-GfTdwSGwknNC-3vQsPPs=.1d1b012a-c4cf-4b83-8b91-b48a2192a6da@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <HnF8kNwvdN0l0ykQRY6nzN6NtbMyRjOy01VQyQDRqew=.8ff6c447-c596-4de1-ac3c-2d9146bd0e1e@github.com>
 <9e3JH2ZJGP1wW1i5pA56IHk2MKaOu-FTFv_xZrUlFu4=.5a879e52-753d-4b0d-b806-a9ae2de6104d@github.com>
 <2IKFVSuqBXDLfk2E4YprOy3liO5_tuVTrA81m_osJmY=.ef604d55-6b75-4bbd-a451-dcb7a839609b@github.com>
 <10g0iPiQojYL5nY_Ifr8Dq-GfTdwSGwknNC-3vQsPPs=.1d1b012a-c4cf-4b83-8b91-b48a2192a6da@github.com>
Message-ID: <vipEqorfOvH5L-KfoD-loUuuQkre_mIgCrNR4_GKVF8=.af68a05a-337f-4325-aec6-e4ce6fd5e3ea@github.com>

On Fri, 15 Aug 2025 23:40:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> That does make sense. Updated in the new commit. Thanks! @magicus @kimbarrett
>
> I think using `DEBUG_LEVEL != release` isn't right for either of these places, since it means we're adding
> the option for "optimize" builds. But doing so here is consistent. I will file a separate issue to address the
> "optimize" build case"

Actually, I think I'm wrong about that. DEBUG_LEVEL is never "optimized", only
HOTSPOT_DEBUG_LEVEL uses that value. If DEBUG_LEVEL is initially "optimized"
it gets forced to "release" in the --with-debug-level handling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26755#discussion_r2280042546

From jpai at openjdk.org  Mon Aug 18 02:05:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 02:05:15 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
Message-ID: <bFlFxpMcrvsKtTmBzlQoavgJDoPdKp8wvnkJfefW3WQ=.09582b59-b841-4801-b15b-d84054a0d477@github.com>

On Fri, 15 Aug 2025 14:18:57 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> Fei Gao 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:
> 
>  - Add flag in debug builds and nothing in release builds
>  - Merge branch 'master' into switch-pattern-to-zero
>  - 8365312: __builtin_clear_padding not supported for variable length aggregates
>    
>    `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added
>    recently to help detect uses of uninitialized memory. [2] Under
>    this extension mode, `__builtin_clear_padding` is called to clear
>    the padding bits in object representation. But the builtin function
>    does not support variable length aggregates [3].
>    
>    `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is
>    defined as an opaque sizeless type in ARM C Language Extensions
>    (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type,
>    it triggers the unsupported code path and results in build failures
>    when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>    
>    Switching the initialization mode with gcc-12 from `pattern` to `zero`
>    avoids the use of this unsupported `__builtin_clear_padding` and
>    resolves the issue.
>    
>    I did not encounter similar problems when building with Clang-16 [6].
>    
>    This patch changes the initialization mode from `pattern` to `zero`
>    when compiling libsleef SVE component on Linux-AArch64 with gcc-12
>    to fix the build failure and help avoid potential security issues
>    related to uninitialized padding
>    
>    Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>    1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>    2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and
>       NEON machines
>    
>    [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>    [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>    [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>    [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>    [5] https://bugs.openjdk.org/browse/JDK-8364185
>    [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

tier1, tier2 and tier3 testing of the latest state of this PR and https://github.com/openjdk/jdk/pull/26577 against latest JDK master branch completed successfully.

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3194869535

From syan at openjdk.org  Mon Aug 18 07:07:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 18 Aug 2025 07:07:18 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
Message-ID: <3-MvAbK7qGpsTlpQAEzwNFpIVH_Z1QJWlUEE5EKofNk=.d5b1767c-1e72-4177-bb6f-21641f5d8f46@github.com>

On Fri, 15 Aug 2025 15:46:58 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
>> 
>> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce nesting levels

make/autoconf/flags-other.m4 line 118:

> 116:     BASIC_ASFLAGS="-x assembler-with-cpp"
> 117:   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
> 118:     BASIC_ASFLAGS="-nologo -c"

Should we need to update the copyright year from 2024 to 2025

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2281479220

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
>
> make/RunTests.gmk line 940:
> 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
> 
> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> make/RunTests.gmk line 940:
>> 
>>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
>> 
>> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> Would you mind also running tier9 to avoid surprises there.

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195900610

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

If there are no mayor objections, I will update the copyrights before I leave work today.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195923727

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196281299

From vyazici at openjdk.org  Mon Aug 18 12:37:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 12:37:52 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <1n3auKF1Wf9oFo_JUNvE2aPXwsxggnoOjLsV49slvs4=.ca7b59fb-4404-41a8-a5ed-fcf66f6bd771@github.com>

On Mon, 18 Aug 2025 12:29:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

I've noticed several architectures don't work for OL either, but I guess that is for another JBS-PR pair.

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

PR Comment: https://git.openjdk.org/jdk/pull/26821#issuecomment-3196524557

From vyazici at openjdk.org  Mon Aug 18 12:37:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 12:37:52 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
Message-ID: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>

In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

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

Commit messages:
 - Update build docs
 - Fix Fedora links
 - Remove `ppc64`

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

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

From erikj at openjdk.org  Mon Aug 18 12:55:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Aug 2025 12:55:13 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v2]
In-Reply-To: <3-MvAbK7qGpsTlpQAEzwNFpIVH_Z1QJWlUEE5EKofNk=.d5b1767c-1e72-4177-bb6f-21641f5d8f46@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <7ZWjbpAEZ4BjtLQghAQsR8AlGmYAdNYbP98LAFtZzD4=.de75c686-1222-4f1a-8a0d-6392735efb85@github.com>
 <3-MvAbK7qGpsTlpQAEzwNFpIVH_Z1QJWlUEE5EKofNk=.d5b1767c-1e72-4177-bb6f-21641f5d8f46@github.com>
Message-ID: <Qujt_uHEw9QQWsl7c4eIxPq_iuZIWQ2HpcrHHGgODnQ=.e31387f9-e74e-44c9-a890-8ce4114a1d9f@github.com>

On Mon, 18 Aug 2025 07:04:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce nesting levels
>
> make/autoconf/flags-other.m4 line 118:
> 
>> 116:     BASIC_ASFLAGS="-x assembler-with-cpp"
>> 117:   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
>> 118:     BASIC_ASFLAGS="-nologo -c"
> 
> Should we need to update the copyright year from 2024 to 2025

Yes, please that would be good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2282312830

From erikj at openjdk.org  Mon Aug 18 13:00:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Aug 2025 13:00:11 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <O72npJKZttS9VIyjVPi9uaNqDWmWlbYwYCxdutA9dk0=.12045e57-7e6e-490e-bb9f-3662ed9fd29c@github.com>

On Mon, 18 Aug 2025 12:29:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26821#pullrequestreview-3128266176

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196793327

From fgao at openjdk.org  Mon Aug 18 13:22:16 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 18 Aug 2025 13:22:16 GMT
Subject: RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern [v2]
In-Reply-To: <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
 <tXhN1fumLxv4tKTE5ANMP4bY3Fmyh35YsS4vk8ujgbQ=.70955989-398f-4607-83ee-959fc7eb180a@github.com>
Message-ID: <3qSj-kBRInVNO_u-gawXQ429rSzzIIdBId8dBro4P4E=.7f89bea4-9a45-4780-a143-f76ca3dc1338@github.com>

On Fri, 15 Aug 2025 14:18:57 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
>> 
>> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>> 
>> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
>> 
>> I did not encounter similar problems when building with Clang-16 [6].
>> 
>> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
>> 
>> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
>> 
>> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>> [5] https://bugs.openjdk.org/browse/JDK-8364185
>> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html
>
> Fei Gao 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:
> 
>  - Add flag in debug builds and nothing in release builds
>  - Merge branch 'master' into switch-pattern-to-zero
>  - 8365312: __builtin_clear_padding not supported for variable length aggregates
>    
>    `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added
>    recently to help detect uses of uninitialized memory. [2] Under
>    this extension mode, `__builtin_clear_padding` is called to clear
>    the padding bits in object representation. But the builtin function
>    does not support variable length aggregates [3].
>    
>    `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is
>    defined as an opaque sizeless type in ARM C Language Extensions
>    (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type,
>    it triggers the unsupported code path and results in build failures
>    when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
>    
>    Switching the initialization mode with gcc-12 from `pattern` to `zero`
>    avoids the use of this unsupported `__builtin_clear_padding` and
>    resolves the issue.
>    
>    I did not encounter similar problems when building with Clang-16 [6].
>    
>    This patch changes the initialization mode from `pattern` to `zero`
>    when compiling libsleef SVE component on Linux-AArch64 with gcc-12
>    to fix the build failure and help avoid potential security issues
>    related to uninitialized padding
>    
>    Testing (combined with https://github.com/openjdk/jdk/pull/26577):
>    1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
>    2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and
>       NEON machines
>    
>    [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>    [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
>    [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
>    [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
>    [5] https://bugs.openjdk.org/browse/JDK-8364185
>    [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

As suggested by @theRealAph in https://github.com/openjdk/jdk/pull/26577#issuecomment-3151114003, I?ve submitted a GCC bug report for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121584.

Thanks so much for all your reviews @magicus @erikj79 @kimbarrett .

And thank you for your testing @jaikiran !

I'll integrate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3196835536

From shade at openjdk.org  Mon Aug 18 14:01:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 14:01:12 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>

On Mon, 18 Aug 2025 12:29:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

Fedora changes look fine, but there is a stray update in docs that we should not be doing, AFAICS:

doc/building.md line 1404:

> 1402: | armel        | buster       | arm           | arm-linux-gnueabi        | zero                      |
> 1403: | ppc          | sid          | powerpc       | powerpc-linux-gnu        | zero                      |
> 1404: | ppc64be      | sid          | ppc64         | powerpc64-linux-gnu      | (all)                     |

This one is not about Fedora, but about Debian-based sysroot. I have not checked recently, but I suspect it would still work, as Debian PPC64 BE port is still alive: https://wiki.debian.org/PPC64

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

PR Review: https://git.openjdk.org/jdk/pull/26821#pullrequestreview-3128508467
PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2282495237

From lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197186029

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@github.com>

On Fri, 15 Aug 2025 11:43:33 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:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

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

From duke at openjdk.org  Mon Aug 18 16:22:56 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Mon, 18 Aug 2025 16:22:56 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v3]
In-Reply-To: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
Message-ID: <-z4DtbPqLk39gv-FXNmg_dvGnoLneAapGPYbojdWzP0=.78476c6b-5343-4c9f-bae9-710cd6cf545b@github.com>

> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
> 
> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

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

  Update the copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26791/files
  - new: https://git.openjdk.org/jdk/pull/26791/files/2ae8f30c..3470f000

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

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

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

From duke at openjdk.org  Mon Aug 18 16:27:14 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Mon, 18 Aug 2025 16:27:14 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v3]
In-Reply-To: <MBEQVClQj8p-Lt5XPrFBDN0-pT1yrad7vO3d8MmuYiI=.fcf48bd3-7dc4-490d-9413-ec39eb691488@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>
 <cszVLDnXYlAGWyA2mSy9kwmzppRLPwYEZnbpeFY9tRo=.258da448-4d7a-4666-81b6-567569a5b3d2@github.com>
 <MBEQVClQj8p-Lt5XPrFBDN0-pT1yrad7vO3d8MmuYiI=.fcf48bd3-7dc4-490d-9413-ec39eb691488@github.com>
Message-ID: <pMDfSe_GIR0m544nK8BItWY4n0zkoXprv2DO2R-110Y=.6d4537d3-f405-4582-b228-0a7f45043cac@github.com>

On Fri, 15 Aug 2025 16:42:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I wonder why we still have the assembler for 32 bit, as the JDK no longer supports 32 bit Windows ever since Magnus nuked it from the codebase

I have filed https://bugs.openjdk.org/browse/JDK-8365707 to address that issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2282883070

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@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:

  after suggestion from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

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

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 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 Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197614389

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 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:
> 
>   after suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197675337

From ihse at openjdk.org  Mon Aug 18 19:32:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Aug 2025 19:32:38 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
Message-ID: <MLNwo-z3_l9_2WNj24aRoDdVzrZbsD9bwLV08iAwXbQ=.9033027c-071d-4200-8ed6-f011d559c882@github.com>

On Mon, 18 Aug 2025 13:57:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.
>
> doc/building.md line 1404:
> 
>> 1402: | armel        | buster       | arm           | arm-linux-gnueabi        | zero                      |
>> 1403: | ppc          | sid          | powerpc       | powerpc-linux-gnu        | zero                      |
>> 1404: | ppc64be      | sid          | ppc64         | powerpc64-linux-gnu      | (all)                     |
> 
> This one is not about Fedora, but about Debian-based sysroot. I have not checked recently, but I suspect it would still work, as Debian PPC64 BE port is still alive: https://wiki.debian.org/PPC64

I think all our ppc64 code assumes le by now, so even if we could get a sysroot for ppc64be to work, I doubt it will do much good for the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2283261691

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

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

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

From vyazici at openjdk.org  Tue Aug 19 05:14:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 05:14:43 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
Message-ID: <J2bzQ-o9mUwf_REsOJMbnJ-jex4KxYmtRRVPo9pmLrg=.8e93eaf4-5bb4-44b5-b37a-13920f438212@github.com>

On Mon, 18 Aug 2025 13:57:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.
>
> doc/building.md line 1404:
> 
>> 1402: | armel        | buster       | arm           | arm-linux-gnueabi        | zero                      |
>> 1403: | ppc          | sid          | powerpc       | powerpc-linux-gnu        | zero                      |
>> 1404: | ppc64be      | sid          | ppc64         | powerpc64-linux-gnu      | (all)                     |
> 
> This one is not about Fedora, but about Debian-based sysroot. I have not checked recently, but I suspect it would still work, as Debian PPC64 BE port is still alive: https://wiki.debian.org/PPC64

@shipilev, thanks so much for the review. ? I was thinking in the same with @magicus while removing this row. Do you still prefer to keep it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2284076853

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 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:
> 
>   after suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199288818

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

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

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

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

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

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

From fgao at openjdk.org  Tue Aug 19 08:25:50 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 19 Aug 2025 08:25:50 GMT
Subject: Integrated: 8365312: GCC 12 cannot compile SVE on aarch64 with
 auto-var-init pattern
In-Reply-To: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
References: <xhrl9xIJCm6Y3ORmAxoZEJpwOwp8hl7YFIILMVnXNnY=.8ccb3caa-281a-438f-91ce-b72917116975@github.com>
Message-ID: <aTGwQsFQU5hH9D63ywpj-dC1ItIqNxQRqYVPN4Yl6wE=.913d8c6e-6255-4b1f-a088-a9b631ff4f18@github.com>

On Wed, 13 Aug 2025 09:16:15 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently to help detect uses of uninitialized memory. [2] Under this extension mode, `__builtin_clear_padding` is called to clear the padding bits in object representation. But the builtin function does not support variable length aggregates [3].
> 
> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When `__builtin_clear_padding` is applied to such a type, it triggers the unsupported code path and results in build failures when compiling libsleef on Linux-AArch64, as reported in JDK-8364185 [5].
> 
> Switching the initialization mode with gcc-12 from `pattern` to `zero` avoids the use of this unsupported `__builtin_clear_padding` and resolves the issue.
> 
> I did not encounter similar problems when building with Clang-16 [6].
> 
> This patch changes the initialization mode from `pattern` to `zero` when compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the build failure and help avoid potential security issues related to uninitialized padding
> 
> Testing (combined with https://github.com/openjdk/jdk/pull/26577):
> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16
> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON machines
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> [2] https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html
> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh
> [5] https://bugs.openjdk.org/browse/JDK-8364185
> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

This pull request has now been integrated.

Changeset: 999761d0
Author:    Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/999761d0f6d37c9cd6ec482620800b694c5fb9ad
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8365312: GCC 12 cannot compile SVE on aarch64 with auto-var-init pattern

Reviewed-by: kbarrett, ihse, erikj

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

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

From fgao at openjdk.org  Tue Aug 19 08:36:17 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 19 Aug 2025 08:36:17 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math operations
 are not supported after JDK-8353217
Message-ID: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>

This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
exceptions on 256-bit `sve` machines with errors like:
`java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`

`test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

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

Commit messages:
 - Split into two separate tasks
 - Merge branch 'master' into redo-jdk8364184
 - 8364184: [REDO] AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217

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

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

From aph at openjdk.org  Tue Aug 19 08:36:17 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 19 Aug 2025 08:36:17 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <YyHxYOPl_KsWFzGR2tIaAKgYj8SVTFsAoXImYup0LpU=.6fdd5382-4f7d-4089-bf63-9d1c0cf8dcb7@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

Can we link this with a GCC bug report?

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3143856420

From fgao at openjdk.org  Tue Aug 19 08:36:17 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 19 Aug 2025 08:36:17 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <YyHxYOPl_KsWFzGR2tIaAKgYj8SVTFsAoXImYup0LpU=.6fdd5382-4f7d-4089-bf63-9d1c0cf8dcb7@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
 <YyHxYOPl_KsWFzGR2tIaAKgYj8SVTFsAoXImYup0LpU=.6fdd5382-4f7d-4089-bf63-9d1c0cf8dcb7@github.com>
Message-ID: <WvUpHGT8OxySWjOAzf4MtExNMT1gGCI0A_ALNAdCv5s=.2273e090-6007-441b-b5e0-e7b0eae0f64a@github.com>

On Fri, 1 Aug 2025 09:19:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Can we link this with a GCC bug report?

@theRealAph thanks for taking a look at this. It looks like there have already been a few related discussions. The feature author mentioned that there are no current plans to support VLAs. See the discussion in [GCC Bug 103374](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103374), and a newer one in [GCC Bug 119381](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381). Are you suggesting that we should open a new report?

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3150830743

From aph at openjdk.org  Tue Aug 19 08:36:17 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 19 Aug 2025 08:36:17 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <WvUpHGT8OxySWjOAzf4MtExNMT1gGCI0A_ALNAdCv5s=.2273e090-6007-441b-b5e0-e7b0eae0f64a@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
 <YyHxYOPl_KsWFzGR2tIaAKgYj8SVTFsAoXImYup0LpU=.6fdd5382-4f7d-4089-bf63-9d1c0cf8dcb7@github.com>
 <WvUpHGT8OxySWjOAzf4MtExNMT1gGCI0A_ALNAdCv5s=.2273e090-6007-441b-b5e0-e7b0eae0f64a@github.com>
Message-ID: <HuXRKWbCozIX5aKU0uZrZJM3fLaqvNN9hfvqZYns4nA=.fc57d28b-b4b5-4c1e-8dc9-62daa1b6b519@github.com>

On Mon, 4 Aug 2025 13:57:31 GMT, Fei Gao <fgao at openjdk.org> wrote:

> > Can we link this with a GCC bug report?
> 
> @theRealAph thanks for taking a look at this. It looks like there have already been a few related discussions. The feature author mentioned that there are no current plans to support VLAs. See the discussion in [GCC Bug 103374](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103374), and a newer one in [GCC Bug 119381](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381). Are you suggesting that we should open a new report?

I'm trying to understand if this is a bug in GCC. It appears that it is: `-ftrivial-auto-var-init=pattern` is incompatible with opaque sizeless types in ARM C Language Extensions (ACLE). There is no workaround for it.

So, this patch is reasonable, but please submit a GCC bug report of "`-ftrivial-auto-var-init=pattern` is incompatible with opaque sizeless types in ARM C Language Extensions (ACLE)." Otherwise GCC authors won't know. This might encourage Jakub to fix `-ftrivial-auto-var-init=pattern` .

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3151114003

From ihse at openjdk.org  Tue Aug 19 08:36:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 19 Aug 2025 08:36:18 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <CznHDyocwjw4x2QG1mLtNZabUz_ZC0OMk4FBEEZC1jE=.a8ca090d-cd7e-4ff2-90a3-ec6cdecdb8c8@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

Looks good, thanks for sorting this out! Note that this is dependent on https://github.com/openjdk/jdk/pull/26755.

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

> 941:   # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
> 942:   # that check.
> 943:   if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_CPU" = "xlinux"; then

This is really disturbing! Has really no-one noticed until now that SVE support broke with 8353217?

Also, this PR fixes two unrelated errors -- a bug introduced in JDK-8353217, and a compiler error. I think it would be better for everybody's sanity, and future backport efforts, if you split it into two.

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3187817040
PR Review Comment: https://git.openjdk.org/jdk/pull/26577#discussion_r2266095631

From fgao at openjdk.org  Tue Aug 19 08:36:18 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 19 Aug 2025 08:36:18 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <CznHDyocwjw4x2QG1mLtNZabUz_ZC0OMk4FBEEZC1jE=.a8ca090d-cd7e-4ff2-90a3-ec6cdecdb8c8@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
 <CznHDyocwjw4x2QG1mLtNZabUz_ZC0OMk4FBEEZC1jE=.a8ca090d-cd7e-4ff2-90a3-ec6cdecdb8c8@github.com>
Message-ID: <oarJRv8MzMFhEDaxpJnf3izRjV1vhhakwcORSx_2p9w=.04f03e30-93e3-4745-a8b4-58197627e61a@github.com>

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

>> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
>> exceptions on 256-bit `sve` machines with errors like:
>> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
>> 
>> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.
>
> make/autoconf/flags-cflags.m4 line 943:
> 
>> 941:   # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
>> 942:   # that check.
>> 943:   if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_CPU" = "xlinux"; then
> 
> This is really disturbing! Has really no-one noticed until now that SVE support broke with 8353217?
> 
> Also, this PR fixes two unrelated errors -- a bug introduced in JDK-8353217, and a compiler error. I think it would be better for everybody's sanity, and future backport efforts, if you split it into two.

@magicus thanks for reviewing this. That sounds reasonable. 

I?ve prepared a new version of the code that resolves the `gcc `error without introducing any compatibility issues. My plan is to first fix the `gcc` issue, and then follow up with a separate patch to address the bug introduced in [JDK-8353217](https://bugs.openjdk.org/browse/JDK-8353217). Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26577#discussion_r2269137672

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199869795

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

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

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

From shade at openjdk.org  Tue Aug 19 10:34:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 10:34:51 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <J2bzQ-o9mUwf_REsOJMbnJ-jex4KxYmtRRVPo9pmLrg=.8e93eaf4-5bb4-44b5-b37a-13920f438212@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
 <J2bzQ-o9mUwf_REsOJMbnJ-jex4KxYmtRRVPo9pmLrg=.8e93eaf4-5bb4-44b5-b37a-13920f438212@github.com>
Message-ID: <SaJFe_dIOUE3luN-JQIpOJKStve9QkJKFd6g8Ojl4TA=.61b85bee-eaa6-427d-9053-58c7bc80fdd1@github.com>

On Tue, 19 Aug 2025 05:12:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> doc/building.md line 1404:
>> 
>>> 1402: | armel        | buster       | arm           | arm-linux-gnueabi        | zero                      |
>>> 1403: | ppc          | sid          | powerpc       | powerpc-linux-gnu        | zero                      |
>>> 1404: | ppc64be      | sid          | ppc64         | powerpc64-linux-gnu      | (all)                     |
>> 
>> This one is not about Fedora, but about Debian-based sysroot. I have not checked recently, but I suspect it would still work, as Debian PPC64 BE port is still alive: https://wiki.debian.org/PPC64
>
> @shipilev, thanks so much for the review. ? I was thinking in the same with @magicus while removing this row. Do you still prefer to keep it?

This list is also _not_ about Fedora devkit, and the PR is about Fedora devkit, so we are doing unrelated work here, regardless if it makes sense or not :) So yes, I prefer to keep it.

> I think all our ppc64 code assumes le by now, so even if we could get a sysroot for ppc64be to work, I doubt it will do much good for the JDK.

I believe Zero is still fine with BE. 

Anyhow, we are doing these cross-compilation instructions largely to support the poor souls who are tasked with maintaining the unusual ports. So if Debian PPC64 BE port is alive, which I think it is, that would mean they build OpenJDK, that would mean they build _some_ PPC64BE config, whether Zero (more likely) or Server (unlikely, as it is probably broken).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2284832460

From fgao at openjdk.org  Tue Aug 19 12:34:37 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 19 Aug 2025 12:34:37 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <l09ELlb9bf7mHvrRa26gmC_9eB-aLfw7Ox35NBqfaWI=.83c0db04-1200-474a-8252-4314c5558530@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

The issue reported in [JDK-8364185](https://bugs.openjdk.org/browse/JDK-8364185) has been addressed separately in https://github.com/openjdk/jdk/pull/26755, which has now been integrated. 

Tier1, tier2 and tier3 testing of this PR and https://github.com/openjdk/jdk/pull/26755 completed successfully, see https://github.com/openjdk/jdk/pull/26755#issuecomment-3194869535.

I believe this pull request is ready for review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3200571629

From vyazici at openjdk.org  Tue Aug 19 14:48:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 14:48:34 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Run `update-build-docs`
 - Revert `ppc64be` removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26821/files
  - new: https://git.openjdk.org/jdk/pull/26821/files/91acc87a..c320f258

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

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

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

From vyazici at openjdk.org  Tue Aug 19 14:48:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 14:48:35 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <SaJFe_dIOUE3luN-JQIpOJKStve9QkJKFd6g8Ojl4TA=.61b85bee-eaa6-427d-9053-58c7bc80fdd1@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
 <J2bzQ-o9mUwf_REsOJMbnJ-jex4KxYmtRRVPo9pmLrg=.8e93eaf4-5bb4-44b5-b37a-13920f438212@github.com>
 <SaJFe_dIOUE3luN-JQIpOJKStve9QkJKFd6g8Ojl4TA=.61b85bee-eaa6-427d-9053-58c7bc80fdd1@github.com>
Message-ID: <goyFiTVFsdZWqTcvxsxbwr-Jq9O28DJD72-W3vsuLdE=.586128be-faad-4523-9091-98e75c842d0c@github.com>

On Tue, 19 Aug 2025 10:31:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev, thanks so much for the review. ? I was thinking in the same with @magicus while removing this row. Do you still prefer to keep it?
>
> This list is also _not_ about Fedora devkit, and the PR is about Fedora devkit, so we are doing unrelated work here, regardless if it makes sense or not :) So yes, I prefer to keep it.
> 
>> I think all our ppc64 code assumes le by now, so even if we could get a sysroot for ppc64be to work, I doubt it will do much good for the JDK.
> 
> I believe Zero is still fine with BE. 
> 
> Anyhow, we are doing these cross-compilation instructions largely to support the poor souls who are tasked with maintaining the unusual ports. So if Debian PPC64 BE port is alive, which I think it is, that would mean they build OpenJDK, that would mean they build _some_ PPC64BE config, whether Zero (more likely) or Server (unlikely, as it is probably broken).

Introduced it back in 69344b10.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2285499552

From stuefe at openjdk.org  Tue Aug 19 14:55:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Aug 2025 14:55:47 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <goyFiTVFsdZWqTcvxsxbwr-Jq9O28DJD72-W3vsuLdE=.586128be-faad-4523-9091-98e75c842d0c@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <TTsxxkS1mZsGW_eKc6m1wpOfRQgANgemEK-M1aurgww=.134c5e7f-5fa2-434a-aa2a-257d2515e8c2@github.com>
 <J2bzQ-o9mUwf_REsOJMbnJ-jex4KxYmtRRVPo9pmLrg=.8e93eaf4-5bb4-44b5-b37a-13920f438212@github.com>
 <SaJFe_dIOUE3luN-JQIpOJKStve9QkJKFd6g8Ojl4TA=.61b85bee-eaa6-427d-9053-58c7bc80fdd1@github.com>
 <goyFiTVFsdZWqTcvxsxbwr-Jq9O28DJD72-W3vsuLdE=.586128be-faad-4523-9091-98e75c842d0c@github.com>
Message-ID: <clQ1Em80IywAhL_t5b_7VNpcBM6xh-RiTh8NVFN2mmY=.2f595ee4-677a-4072-b829-eb52d1c70885@github.com>

On Tue, 19 Aug 2025 14:41:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> This list is also _not_ about Fedora devkit, and the PR is about Fedora devkit, so we are doing unrelated work here, regardless if it makes sense or not :) So yes, I prefer to keep it.
>> 
>>> I think all our ppc64 code assumes le by now, so even if we could get a sysroot for ppc64be to work, I doubt it will do much good for the JDK.
>> 
>> I believe Zero is still fine with BE. 
>> 
>> Anyhow, we are doing these cross-compilation instructions largely to support the poor souls who are tasked with maintaining the unusual ports. So if Debian PPC64 BE port is alive, which I think it is, that would mean they build OpenJDK, that would mean they build _some_ PPC64BE config, whether Zero (more likely) or Server (unlikely, as it is probably broken).
>
> Introduced it back in 69344b10.

> I think all our ppc64 code assumes le by now, so even if we could get a sysroot for ppc64be to work, I doubt it will do much good for the JDK.

FYI, and completely irrelevant for this PR, but AIX is still ppcbe. The only big endian platform left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2285532131

From shade at openjdk.org  Tue Aug 19 14:58:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 14:58:42 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>
Message-ID: <bPq_VZ934qv3XXiSLZiEb4_C3XWKMG6-bbqBN-ypQsg=.3770dadc-39dd-4339-acd5-8158961cc418@github.com>

On Tue, 19 Aug 2025 14:48:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run `update-build-docs`
>  - Revert `ppc64be` removal

Looks fine, thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26821#pullrequestreview-3132724481

From duke at openjdk.org  Wed Aug 20 00:44:47 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 20 Aug 2025 00:44:47 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency
In-Reply-To: <XFZFmRA7a3tmFMxncTD8qyDqrGlwf8fRPYDtrgNfcv4=.73afe13b-4176-4b30-8a9c-bbbac8ec3408@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <SJ5-ueS7rP5Cgc35kAoWNmcMTwy8gtaVTYh4iFFPDfw=.e1631af4-1c03-44ef-8f2c-61e19cf5709b@github.com>
 <n2MHG_EGiGVrlpsOUs9xcgDF8GxdIRm9avAum6G5jVY=.545f085d-8947-4ff6-b84c-5a3bfb1f1255@github.com>
 <JqmB0VEJQOXUqDUyin1nAe7PmiaHHayrW73ZhjtyCY0=.14a5018c-04cf-4276-833a-2b0e2e34073a@github.com>
 <XFZFmRA7a3tmFMxncTD8qyDqrGlwf8fRPYDtrgNfcv4=.73afe13b-4176-4b30-8a9c-bbbac8ec3408@github.com>
Message-ID: <QalgYaNDxxGFdraSu2YqQHxMcPrAwtEjMrDAfkjihp0=.3612af25-9df0-40d4-a9fc-e8156a44ad21@github.com>

On Fri, 8 Aug 2025 10:27:30 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> > For example, when the threshold is set to 50 I get this compilation error:
> 
> How can we possibly get a compilation error when everything should build with PCH disabled?

@dholmes-ora FYI I tracked the failure and opened a ticket: https://bugs.openjdk.org/browse/JDK-8365829

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3203544026

From ihse at openjdk.org  Wed Aug 20 06:44:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 06:44:43 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>
Message-ID: <SJsjC_xxETurYlGFpU-f106Cfa_-Rw8g_L2usF0xJ0Y=.05f9fc9f-7942-4115-8b1f-85e0a9e64c97@github.com>

On Tue, 19 Aug 2025 14:48:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run `update-build-docs`
>  - Revert `ppc64be` removal

make/devkit/Tools.gmk line 76:

> 74:   endif
> 75:   ifeq ($(ARCH), riscv64)
> 76:     ifeq ($(filter 36 37, $(BASE_OS_VERSION)), )

The test and the error message does not match up.

make/devkit/Tools.gmk line 88:

> 86:     endif
> 87:     ifeq ($(ARCH), armhfp)
> 88:       ifneq ($(BASE_OS_VERSION),36)

Suggestion:

      ifneq ($(BASE_OS_VERSION), 36)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2287140943
PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2287144658

From ihse at openjdk.org  Wed Aug 20 06:47:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 06:47:40 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <TaKPz_7KZkXp5YAky08FXyrmGDvMt26cyKIm2ge1z40=.5da28e06-d513-4ba0-ade0-93653622b4b1@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

LGTM

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26577#pullrequestreview-3135008209

From aboldtch at openjdk.org  Wed Aug 20 07:12:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 20 Aug 2025 07:12:56 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
Message-ID: <sAiXD7K5wFHgucL6WOPyjDzGC2G5h2My8pItOLF0eK8=.90458b2c-cb24-4118-bf30-b1a03a3a7228@github.com>

On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - conditional includes
>  - variants

I have a few questions/comments.

There are now a bunch of unconditional includes for JVM features which can be disabled. With the exception of CDS, in the rest of the codebase we have been very careful to always guard these includes when using them outside their own sub-components. 

I understand that these are generated includes, but I think we can curate the list some manually.

Currently `c1/c1_globals.hpp` `jvmci/jvmci_globals.hpp` and `opto/c2_globals.hpp` are included which are optional features, `compiler/compiler_globals.hpp` (which is also included) should be used instead. Same goes for `gc/serial/serial_globals.hpp` and `gc/shared/gc_globals.hpp`.

In addition to those globals files we have all the JFR and CDS includes which are unguarded.

I am not sure I understand completely what goes into the list of conditional includes here. I understand that there might be duplicates across the different conditional includes, but now there are also includes which are duplicated in the unconditional includes. So is it a list of all includes which are beneficial when building with just that feature, or is it suppose to be a list of extra includes which are beneficial if that feature is enabled. Or are those lists something else?

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

PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3135090453

From vyazici at openjdk.org  Wed Aug 20 07:29:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 07:29:43 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v3]
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <vYZRb6X5p43aqwhUvh0ZHfI6FhMweREdsjfiIAaEre8=.acd64388-1b28-4424-8039-3ddb44083992@github.com>

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

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

  Fix whitespace
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26821/files
  - new: https://git.openjdk.org/jdk/pull/26821/files/c320f258..2b30b3b8

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

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

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

From vyazici at openjdk.org  Wed Aug 20 07:38:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 07:38:26 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v4]
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <1EkvhqJiv_SxJ26Hc6rsHcN3dCHfHcQXEKvR97x4jtk=.ee29465c-67e1-4c10-86be-325bb86b75a2@github.com>

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

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

  Fix Fedora riscv64 version filter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26821/files
  - new: https://git.openjdk.org/jdk/pull/26821/files/2b30b3b8..bdee4cae

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

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

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

From vyazici at openjdk.org  Wed Aug 20 07:38:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 07:38:26 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v2]
In-Reply-To: <SJsjC_xxETurYlGFpU-f106Cfa_-Rw8g_L2usF0xJ0Y=.05f9fc9f-7942-4115-8b1f-85e0a9e64c97@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <cT50kxPe5mlU7o9zWJfb4hN5gqOY7T39AR-sDZbMb2I=.48cf11fb-93ec-489e-9cc2-8a8e65860c92@github.com>
 <SJsjC_xxETurYlGFpU-f106Cfa_-Rw8g_L2usF0xJ0Y=.05f9fc9f-7942-4115-8b1f-85e0a9e64c97@github.com>
Message-ID: <lZOSESGjRyHUEbJ2SaV2sqvTpiyUZcQgu4BU2khnwS0=.da25bcf2-3372-4e7b-beeb-a274919cb973@github.com>

On Wed, 20 Aug 2025 06:40:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Run `update-build-docs`
>>  - Revert `ppc64be` removal
>
> make/devkit/Tools.gmk line 76:
> 
>> 74:   endif
>> 75:   ifeq ($(ARCH), riscv64)
>> 76:     ifeq ($(filter 36 37, $(BASE_OS_VERSION)), )
> 
> The test and the error message does not match up.

Very sharp of you, thanks! ? I should have used `ifneq`. I've replaced the current mind-bending expression with a simpler one in bdee4cae67c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26821#discussion_r2287265983

From aph at openjdk.org  Wed Aug 20 08:49:42 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 20 Aug 2025 08:49:42 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <6fkfPwsRF478Ea8Ld8NJe9Rf9JEboWJwhrMK8kI4plQ=.f632ae6a-4660-4132-918b-c12ba3b75191@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26577#pullrequestreview-3135453459

From fgao at openjdk.org  Wed Aug 20 11:35:45 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 20 Aug 2025 11:35:45 GMT
Subject: RFR: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <HuXRKWbCozIX5aKU0uZrZJM3fLaqvNN9hfvqZYns4nA=.fc57d28b-b4b5-4c1e-8dc9-62daa1b6b519@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
 <YyHxYOPl_KsWFzGR2tIaAKgYj8SVTFsAoXImYup0LpU=.6fdd5382-4f7d-4089-bf63-9d1c0cf8dcb7@github.com>
 <WvUpHGT8OxySWjOAzf4MtExNMT1gGCI0A_ALNAdCv5s=.2273e090-6007-441b-b5e0-e7b0eae0f64a@github.com>
 <HuXRKWbCozIX5aKU0uZrZJM3fLaqvNN9hfvqZYns4nA=.fc57d28b-b4b5-4c1e-8dc9-62daa1b6b519@github.com>
Message-ID: <DavF82q8T4z3p9viipbKlsZUbJtso_E_KamPmLUAiyc=.19211b0f-d9a3-4b16-bfee-143b11562219@github.com>

On Mon, 4 Aug 2025 14:52:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> Can we link this with a GCC bug report?
>> 
>> @theRealAph thanks for taking a look at this. It looks like there have already been a few related discussions. The feature author mentioned that there are no current plans to support VLAs. See the discussion in [GCC Bug 103374](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103374), and a newer one in [GCC Bug 119381](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381). Are you suggesting that we should open a new report?
>
>> > Can we link this with a GCC bug report?
>> 
>> @theRealAph thanks for taking a look at this. It looks like there have already been a few related discussions. The feature author mentioned that there are no current plans to support VLAs. See the discussion in [GCC Bug 103374](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103374), and a newer one in [GCC Bug 119381](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381). Are you suggesting that we should open a new report?
> 
> I'm trying to understand if this is a bug in GCC. It appears that it is: `-ftrivial-auto-var-init=pattern` is incompatible with opaque sizeless types in ARM C Language Extensions (ACLE). There is no workaround for it.
> 
> So, this patch is reasonable, but please submit a GCC bug report of "`-ftrivial-auto-var-init=pattern` is incompatible with opaque sizeless types in ARM C Language Extensions (ACLE)." Otherwise GCC authors won't know. This might encourage Jakub to fix `-ftrivial-auto-var-init=pattern` .

Thanks for approving it @theRealAph @magicus .

I'll integrate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26577#issuecomment-3205824114

From fgao at openjdk.org  Wed Aug 20 11:38:46 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 20 Aug 2025 11:38:46 GMT
Subject: Integrated: 8364184: [REDO] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
References: <OMgzh0DLUUAdFhmD4OOV1gREhWSC4ITtpNWjsKJTe8Y=.daf3530a-c58b-4c1c-859c-e1af2080294e@github.com>
Message-ID: <OoXG0zq8F7Bk5p_jUGW5D5ZFa-eRIWhWi4BrRUUrhLQ=.2e1bcea1-68d5-41e1-866b-27616a6b2213@github.com>

On Thu, 31 Jul 2025 16:14:35 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in JDK-8353217, which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw
> exceptions on 256-bit `sve` machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve.`
> 
> `test/jdk/jdk/incubator/vector` passed on 256-bit `sve` and `neon` machine.

This pull request has now been integrated.

Changeset: 51d710e3
Author:    Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51d710e3cc8ee185a0a305e8efcfd03dda41570b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8364184: [REDO] AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217

Reviewed-by: ihse, aph

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

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

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

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

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

From ihse at openjdk.org  Wed Aug 20 13:07:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 13:07:42 GMT
Subject: RFR: 8362243: Devkit creation for Fedora base OS is broken [v4]
In-Reply-To: <1EkvhqJiv_SxJ26Hc6rsHcN3dCHfHcQXEKvR97x4jtk=.ee29465c-67e1-4c10-86be-325bb86b75a2@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
 <1EkvhqJiv_SxJ26Hc6rsHcN3dCHfHcQXEKvR97x4jtk=.ee29465c-67e1-4c10-86be-325bb86b75a2@github.com>
Message-ID: <v--HoUL05H9c9ZrYKOluet8WqPoaNTwLeVFSleapS34=.3ba2fec4-5a33-4712-95d4-8339e2457fc6@github.com>

On Wed, 20 Aug 2025 07:38:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Fedora riscv64 version filter

LGTM now.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26821#pullrequestreview-3136509440

From ihse at openjdk.org  Wed Aug 20 13:12:47 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 13:12:47 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <sAiXD7K5wFHgucL6WOPyjDzGC2G5h2My8pItOLF0eK8=.90458b2c-cb24-4118-bf30-b1a03a3a7228@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
 <sAiXD7K5wFHgucL6WOPyjDzGC2G5h2My8pItOLF0eK8=.90458b2c-cb24-4118-bf30-b1a03a3a7228@github.com>
Message-ID: <oA-JIGBfO2jxHj9TlXQaDUneBkhNnYze-zY73NOhZWo=.95f680f0-b878-4056-bf1a-3aa9fdd97e80@github.com>

On Wed, 20 Aug 2025 07:10:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> There are now a bunch of unconditional includes for JVM features which can be disabled. 

Hm. Either there is a bug in @fandreuz script, or these files are still included even if you disable all features. The list of unconditional includes is supposed to be generated by building a JVM with no features at all enabled (with the possible exception of epsilon-gc; I believe having at least one GC is a requirement), and then checking which files are indeed included.

My guess is that the logic is not so much as "don't include file c1_foo unless C1 is enabled", as "in c1_foo, guard all contents with an ifdef on C1". So then this is what you'd see in that case.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3206277753

From vyazici at openjdk.org  Wed Aug 20 13:16:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 13:16:53 GMT
Subject: Integrated: 8362243: Devkit creation for Fedora base OS is broken
In-Reply-To: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
References: <0GZersfZNeD4EhZfmYqNniW9lHGz7I3WvmwBdhNC9YE=.63e9864e-7a45-4bce-995e-90e050463cbb@github.com>
Message-ID: <HrAXHnXCwNlvdjX17p0PxTQnW2yXFWi7m15jCiSA-n0=.b2231d76-53ca-4170-8a06-fc56b7f7cdcf@github.com>

On Mon, 18 Aug 2025 12:29:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> In Devkit, removes `ppc64`/`ppc64be`, which is superseded by `ppc64le`, fixes Fedora repository links, and bumps the `LATEST_ARCHIVED_OS_VERSION` to 36.

This pull request has now been integrated.

Changeset: 1383b8ef
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1383b8ef87bcf3b2b498c883c81434bab8fe68fd
Stats:     27 lines in 4 files changed: 12 ins; 1 del; 14 mod

8362243: Devkit creation for Fedora base OS is broken

Reviewed-by: ihse, erikj, shade

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

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

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

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

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

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 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:
> 
>   after suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

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

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

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 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:
> 
>   after suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3206865824

From ihse at openjdk.org  Wed Aug 20 15:31:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:31:44 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v3]
In-Reply-To: <pMDfSe_GIR0m544nK8BItWY4n0zkoXprv2DO2R-110Y=.6d4537d3-f405-4582-b228-0a7f45043cac@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <E_6EM_KTqTwJtol2alVPqKUW6UTFNDSuZ_IapvrrJrw=.b326ba1a-ba4f-427d-bf44-b9d52986504a@github.com>
 <cszVLDnXYlAGWyA2mSy9kwmzppRLPwYEZnbpeFY9tRo=.258da448-4d7a-4666-81b6-567569a5b3d2@github.com>
 <MBEQVClQj8p-Lt5XPrFBDN0-pT1yrad7vO3d8MmuYiI=.fcf48bd3-7dc4-490d-9413-ec39eb691488@github.com>
 <pMDfSe_GIR0m544nK8BItWY4n0zkoXprv2DO2R-110Y=.6d4537d3-f405-4582-b228-0a7f45043cac@github.com>
Message-ID: <O_3pRhrPtLBa37MokRPFHdNwWXG5r-L-LflCz7vDFLA=.baf0099b-d248-4bc9-9929-774927df5389@github.com>

On Mon, 18 Aug 2025 16:24:30 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> I wonder why we still have the assembler for 32 bit, as the JDK no longer supports 32 bit Windows ever since Magnus nuked it from the codebase
>
>> I wonder why we still have the assembler for 32 bit, as the JDK no longer supports 32 bit Windows ever since Magnus nuked it from the codebase
> 
> I have filed https://bugs.openjdk.org/browse/JDK-8365707 to address that issue

Is this really so? The [documentation](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) states:


/Ta filename 	Assembles source file whose name doesn't end with the .asm extension.


We want the compiler to actually do what we tell it to do, even if the files are named .S. 

Maybe this behavior has been changed in later versions, but I am a bit wary about removing it unless we have some official confirmation that `/Ta` is a no-op, and/or information on which version this started to happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26791#discussion_r2288537315

From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

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

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

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

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

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

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@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:

  update testing.md, remove makefile link, fix bad text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

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

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 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 ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

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

From egahlin at openjdk.org  Wed Aug 20 20:52:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Aug 2025 20:52:04 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
Message-ID: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>

Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?

It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.

Testing: test/jdk/jdk/jfr + tier1

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3208143195

From egahlin at openjdk.org  Thu Aug 21 05:21:23 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 21 Aug 2025 05:21:23 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
 [v2]
In-Reply-To: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
Message-ID: <NiSFcXWDjjaCrcmx-N9tZB56w62SdxDRL1QZ1-tD-6o=.3b779395-2677-4e24-8c11-93f92eab2c69@github.com>

> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
> 
> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
> 
> Testing: test/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

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

  Add view output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26869/files
  - new: https://git.openjdk.org/jdk/pull/26869/files/604b86de..9d54c0e5

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

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

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

From lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

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

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

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

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

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

From duke at openjdk.org  Thu Aug 21 10:13:57 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 21 Aug 2025 10:13:57 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
Message-ID: <Afb_wBeCKnfXVQ4o52xYj-NGYWHUI1HR_FS5xsPvflE=.7db163a9-2943-4fd1-b199-43bb77bef6b9@github.com>

On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - conditional includes
>  - variants

I think I found a more sensible approach to tackle this problem. Using clang [`-ftime-trace`](https://clang.llvm.org/docs/analyzer/developer-docs/PerformanceInvestigation.html#performance-analysis-using-ftime-trace) we can get reports in [Trace Event format](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview?tab=t.0) about each header. Example of one such file here: [shenandoahOldGC.json](https://github.com/user-attachments/files/21915502/shenandoahOldGC.json).

These files can be processed (e.g. with [ClangBuildAnalyzer](https://github.com/aras-p/ClangBuildAnalyzer/tree/main)) to dig where time was spent during the build. Among the information we can get from `ClangBuildAnalyzer`, here is the interesting one:

**** Expensive headers:
597169 ms: /jdk/src/hotspot/share/oops/access.inline.hpp (included 650 times, avg 918 ms), included via:
  80x: oop.inline.hpp iterator.inline.hpp 
  70x: javaClasses.inline.hpp 
  40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp 
  39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp 
  32x: g1CollectedHeap.inline.hpp g1ConcurrentMark.inline.hpp g1ConcurrentMarkBitMap.inline.hpp markBitMap.inline.hpp oop.inline.hpp iterator.inline.hpp 
  30x: ciUtilities.inline.hpp interfaceSupport.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp 
  ...

425714 ms: /jdk/src/hotspot/share/memory/iterator.inline.hpp (included 646 times, avg 659 ms), included via:
  80x: oop.inline.hpp 
  70x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 
  40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 
  39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 
  32x: g1CollectedHeap.inline.hpp g1ConcurrentMark.inline.hpp g1ConcurrentMarkBitMap.inline.hpp markBitMap.inline.hpp oop.inline.hpp 
  30x: ciUtilities.inline.hpp interfaceSupport.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp 
  ...

400304 ms: /jdk/src/hotspot/share/oops/oop.inline.hpp (included 1165 times, avg 343 ms), included via:
  80x: <direct include>
  70x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 
  66x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 
  60x: javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp oop.inline.hpp iterator.inline.hpp instanceKlass.inline.hpp klass.inline.hpp classLoaderData.inline.hpp 
  40x: jfrEvents.hpp jfrEventClasses.hpp jfrEvent.hpp jfrNativeEventWriter.hpp jfrEventWriterHost.inline.hpp jfrEventWriterHost.hpp jfrWriterHost.inline.hpp jfrTraceId.inline.hpp javaThread.inline.hpp oopHandle.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 
  39x: shenandoahHeap.inline.hpp javaClasses.inline.hpp access.inline.hpp barrierSet.inline.hpp objArrayOop.inline.hpp 
  ...

[...]


This should give us a clear understanding of which headers should go into `precompiled.hpp`, and uses all information available from the compiler itself, as opposed to counting the number of inclusions. Now, improvements in build time are comparable with the initial approach I tried in this PR, but I think this approach will prove more accurate in the long term.

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3209879924

From ihse at openjdk.org  Thu Aug 21 12:19:01 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:19:01 GMT
Subject: RFR: 8365053: Refresh hotspot precompiled.hpp with headers based
 on current frequency [v11]
In-Reply-To: <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
References: <HPG-MceIruL9UBMr9L1MFdgUoWbfJew07OtEoXGMxOU=.deb9f74a-1d4a-4f3a-b035-a20f866ccdd1@github.com>
 <-Sya8z4PLvQEJQO1dWl5a31ZEFBg5eBrzUjSv5PVGNo=.0e9484ba-8a5e-475a-abd6-05b6e441bd4c@github.com>
Message-ID: <0LwZCnCEv_YJU0E4pfVln83BASYzR6FCPErCCuUnGpw=.7d5a8ca7-c517-416e-ace7-f87f215c9083@github.com>

On Tue, 12 Aug 2025 11:32:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> In this PR I propose to refresh the included headers in hotspot `precompiled.hpp`. The current set of precompiled headers was refreshed in 2018, 7 years ago. I repeated the same operations and measurements after refreshing the set of precompiled headers according to the current usage frequency.
>> 
>> These are the results I observed. Depending on the platform, the improvement is between 10 and 20% in terms of total work (user+sys). The results are in seconds.
>> 
>> 
>> linux-x64 GCC
>> master      real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>> 
>> linux-x64 Clang
>> master      real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>> 
>> linux-aarch64 GCC
>> master      real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>> 
>> linux-aarch64 clang
>> master      real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - conditional includes
>  - variants

That's interesting. Hopefully there is some consistency between compilers of how long time headers take to process. Ideally, we should get the same information from Microsoft CL, but I suspect that is not possible. (Since on Windows PCH makes the largest difference of any platform.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3210358607

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3210365303

From kbarrett at openjdk.org  Thu Aug 21 14:58:31 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 14:58:31 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17
Message-ID: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>

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.

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

Commit messages:
 - fix a couple trailing whitespace issues
 - update style guide for c++17
 - build with c++17

Changes: https://git.openjdk.org/jdk/pull/26884/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314488
  Stats: 1183 lines in 7 files changed: 1097 ins; 35 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/26884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26884/head:pull/26884

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

From jwaters at openjdk.org  Thu Aug 21 15:21:52 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 21 Aug 2025 15:21:52 GMT
Subject: RFR: 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: <XLQhI2wuh5_PEgMS_Y_ubWzY9V3ke03lXYaH_9UBLZw=.c9936026-62e2-48ee-b8ae-9975403cb652@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.

There's a "CXXFLAGS := -std=c++17" in java.base Lib.gmk that's also no longer needed once the switch to C++17 is made (See https://github.com/openjdk/jdk/pull/14988/files)

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

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

From rcastanedalo at openjdk.org  Thu Aug 21 18:26:51 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 21 Aug 2025 18:26:51 GMT
Subject: RFR: 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: <ftF1_ACK2IDF8RcllzOjX5N_kwkgJo_VmwrxmT9j95A=.618459ff-76b3-4070-ac4b-724f0089b112@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.

doc/hotspot-style.html line 1544:

> 1542: <code>second</code> members don't carry any useful information.</p>
> 1543: <h3 id="file-system-library">File System Library</h3>
> 1544: <p>The use of the File System library is forbidden. HotSpot doesn't very

Suggestion:

<p>The use of the File System library is forbidden. HotSpot doesn't do very

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26884#discussion_r2291827441

From kbarrett at openjdk.org  Thu Aug 21 18:43:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Aug 2025 18:43:51 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17
In-Reply-To: <XLQhI2wuh5_PEgMS_Y_ubWzY9V3ke03lXYaH_9UBLZw=.c9936026-62e2-48ee-b8ae-9975403cb652@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
 <XLQhI2wuh5_PEgMS_Y_ubWzY9V3ke03lXYaH_9UBLZw=.c9936026-62e2-48ee-b8ae-9975403cb652@github.com>
Message-ID: <TTP17zRpLE51lsv9zs_IHXIWzeR6BVeibWOdFKg_GJk=.51febdf1-685c-4b74-a730-dc5ab91cea27@github.com>

On Thu, 21 Aug 2025 15:19:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> There's a "CXXFLAGS := -std=c++17" in java.base Lib.gmk that's also no longer needed once the switch to C++17 is made (See https://github.com/openjdk/jdk/pull/14988/files)

Perhaps. Or perhaps that configuration should be sticky, in case that specific version is still needed when we
move to c++20 :)

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

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

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

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

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

From egahlin at openjdk.org  Fri Aug 22 06:09:30 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 22 Aug 2025 06:09:30 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
 [v3]
In-Reply-To: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
Message-ID: <6fDHpUNTm6j5OuFgsDiRpMh3LAYOAUgeayyTA1Eb1h0=.11887e3c-726f-4a74-a985-3e2060a469df@github.com>

> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
> 
> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
> 
> Testing: test/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

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

  Add s

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26869/files
  - new: https://git.openjdk.org/jdk/pull/26869/files/9d54c0e5..d6c88bb0

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

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

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

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr 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/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

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

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

From jsjolen at openjdk.org  Fri Aug 22 11:08:58 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 22 Aug 2025 11:08:58 GMT
Subject: RFR: 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: <n7gynD27NsEkAedSpHNJe0yNAWJ1leNMChaOzUvLQy8=.7eeaef46-ccb3-469c-b470-f755d427b993@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.

Marked as reviewed by jsjolen (Reviewer).

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

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

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

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?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr 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/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

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

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

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

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

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

From kbarrett at openjdk.org  Fri Aug 22 22:18:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 22 Aug 2025 22:18:46 GMT
Subject: RFR: 8314488: Compiling the JDK with C++17 [v2]
In-Reply-To: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
References: <TIggeMmoJWlA5d8mjODfAsnEuEnNk2VT-aBymupBRWo=.54826efd-eee2-4b55-b2f1-6480084a01bb@github.com>
Message-ID: <PW792OfkKKLwZLSA4OaUP1ZFAFWVSsq9Jv_-RbLO44o=.ff8ba391-0668-460f-8ba6-f809e5e28280@github.com>

> 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 one additional commit since the last revision:

  fix missing word

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26884/files
  - new: https://git.openjdk.org/jdk/pull/26884/files/0876cacd..cdd11cce

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

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

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

From duke at openjdk.org  Fri Aug 22 23:52:10 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 22 Aug 2025 23:52:10 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v4]
In-Reply-To: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
Message-ID: <O1TrjblnUKwFhSqB38SQGI2qed4FgRdgv94dhIMotHc=.862222a4-b811-4875-a1a1-041348582d4e@github.com>

> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
> 
> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).

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

  Restore -Ta flag for x64 assembler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26791/files
  - new: https://git.openjdk.org/jdk/pull/26791/files/3470f000..42796378

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

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

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

From ihse at openjdk.org  Sat Aug 23 08:36:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 23 Aug 2025 08:36:53 GMT
Subject: RFR: 8365579: ml64.exe is not the right assembler for Windows
 aarch64 [v4]
In-Reply-To: <O1TrjblnUKwFhSqB38SQGI2qed4FgRdgv94dhIMotHc=.862222a4-b811-4875-a1a1-041348582d4e@github.com>
References: <vOeVTnaZS4sWwX96dT2FVyvhQp9JRfdMxbtQ6Hc33Aw=.5b71c80c-8ca1-4582-a598-0d479af667c2@github.com>
 <O1TrjblnUKwFhSqB38SQGI2qed4FgRdgv94dhIMotHc=.862222a4-b811-4875-a1a1-041348582d4e@github.com>
Message-ID: <ANVGkMsi5TkyIt5639PuYAHHVYc3QH38KqXqYGziqXs=.bb0c620a-b0d2-4f2b-bed8-995fd12ac907@github.com>

On Fri, 22 Aug 2025 23:52:10 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> [ml64](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) is set as the assembler for the Windows platform but is specific to the x64 platform. The [armasm64](https://learn.microsoft.com/en-us/cpp/assembler/arm/arm-assembler-command-line-reference?view=msvc-170) assembler should be used for Windows AArch64.
>> 
>> The -c and -Ta options are only valid for ml64 and -Ta can be removed from CompileFile.gmk (assembling for x64 works without it).
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore -Ta flag for x64 assembler

I'd like to see some more investigation into the removal of `-Ta` before integration, since it is documented as required.

An alternative to investigation is to keep it for ml64, by creating a new variable exposed to spec.gmk, similar to how cl.exe needs a `-out:` (or whatever it was called) for where to .obj files.

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

PR Comment: https://git.openjdk.org/jdk/pull/26791#issuecomment-3216572092