From duke at openjdk.org  Tue Apr  1 01:34:19 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Apr 2025 01:34:19 GMT
Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM
 src/hotspot C++ source files [v4]
In-Reply-To: <nT6MwxltFM8gdqpyOpX9nYMjMXz4uAmwHQGjylMMjM8=.daaf5938-9b02-41ac-b379-48b98c417d86@github.com>
References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com>
 <nT6MwxltFM8gdqpyOpX9nYMjMXz4uAmwHQGjylMMjM8=.daaf5938-9b02-41ac-b379-48b98c417d86@github.com>
Message-ID: <7GINlQl4EFX0tUEmDZkJIqV3EBVuwisaUFwTLoqtn2w=.5798b939-54b6-45ba-af25-43124bcdb632@github.com>

On Mon, 31 Mar 2025 14:31:56 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. 
>> 
>> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`.
>> 
>> This PR does:
>> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected.
>> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`.
>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs.
>> 
>> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks.
>
> Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272
>   
>   Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

@cnqpzhang 
Your change (at version 46c439211cf55388086dcb8fbbaeca52d571ea8d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2767806513

From syan at openjdk.org  Tue Apr  1 07:30:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Apr 2025 07:30:46 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0 [v2]
In-Reply-To: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
Message-ID: <GRYJaAvISB0G__26Qd4eaVp3kWVptInIsFPXv1IqVeE=.1c733d7d-dd76-4562-9dae-d4f6818fa15e@github.com>

> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
> 
> 
>> cat java.c
> char a() {
>   return 0;
>   int b;
>   if (a(&b))
>     return 0;
> }
> 
>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
> java.c: In function ?a?:
> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>     6 | }
>       | ^
> cc1: all warnings being treated as errors

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

  Use #pragma GCC diagnostic ignored "-Wreturn-type" instead of use diasable_warning in makefile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24318/files
  - new: https://git.openjdk.org/jdk/pull/24318/files/78785e27..83beb975

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

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

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

From syan at openjdk.org  Tue Apr  1 07:30:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Apr 2025 07:30:46 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0
In-Reply-To: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
 <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com>
Message-ID: <xs8aPzNMgOKPuY7ktY7MMFDFUliKGdsvflrel7yjGYw=.3f8e3979-8835-42bc-b271-8579b3d4f033@github.com>

On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While I normally advocate using DISABLE_WARNING in makefiles instead of pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro would be better?

PR has been changed to use `#pragma GCC diagnostic ignored "-Wreturn-type"` instead of used DISABLE_WARNING in makefile. Change has been verified locally.

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

PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2768435238

From galder at redhat.com  Tue Apr  1 07:52:30 2025
From: galder at redhat.com (Galder Zamarreno)
Date: Tue, 1 Apr 2025 09:52:30 +0200
Subject: On passing --date to jrt-fs jar at build time
In-Reply-To: <8c6005a3-c196-4917-82ef-ef86e1b0abd6@oracle.com>
References: <CAAcPREun-zQXQweErGeUvJ7_O-aspMau0_gO=UbB1Rrt+z+mKw@mail.gmail.com>
 <8c6005a3-c196-4917-82ef-ef86e1b0abd6@oracle.com>
Message-ID: <CAAcPREuSh4C3HLLNX5JukjoHnpsBtW_pNtDrn0=My+oPEb-kBw@mail.gmail.com>

On Fri, Mar 28, 2025 at 10:43?AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 28/03/2025 09:25, Galder Zamarreno wrote:
>
> :
>
> However, @Thomas Fitzsimmons <fitzsim at redhat.com> had a very good point
> to make:
>
> > I also wonder why the test harness is passing --date $SOURCE_DATE_EPOCH,
> since the test jars are not distributed, not sure why they'd need to be
> reproducible...
>
> I think his question is valid. Why pass --date for a test jar?
>
>
> I'm not sure what "test harness" and "test jar" means here but just to say
> that jrt-fs.jar is in the JDK run-time.
>

^ Are you sure? The default make target, `exploded-image`, doesn't build
the jrt-fs.jar. Aside from `test`, `images` does build the jar.


> When an IDE running on JDK X needs to build/run a project for target JDK Y
> then it will use the jrt file system to access the classes in the target
> JDK. jrt-fs.jar is the provider implementation that JDK X will load to do
> this.
>

If the jar does not mean, seems like an exploded image jdk won't work for ^?


>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250401/cb4d7c30/attachment-0001.htm>

From alan.bateman at oracle.com  Tue Apr  1 08:27:21 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 1 Apr 2025 09:27:21 +0100
Subject: On passing --date to jrt-fs jar at build time
In-Reply-To: <CAAcPREuSh4C3HLLNX5JukjoHnpsBtW_pNtDrn0=My+oPEb-kBw@mail.gmail.com>
References: <CAAcPREun-zQXQweErGeUvJ7_O-aspMau0_gO=UbB1Rrt+z+mKw@mail.gmail.com>
 <8c6005a3-c196-4917-82ef-ef86e1b0abd6@oracle.com>
 <CAAcPREuSh4C3HLLNX5JukjoHnpsBtW_pNtDrn0=My+oPEb-kBw@mail.gmail.com>
Message-ID: <e55d7b37-c0bd-4ac0-8938-caf47faf2630@oracle.com>

On 01/04/2025 08:52, Galder Zamarreno wrote:
>
>
>     I'm not sure what "test harness" and "test jar" means here but
>     just to say that jrt-fs.jar is in the JDK run-time.
>
>
> ^ Are you sure? The default make target, `exploded-image`, doesn't 
> build the jrt-fs.jar. Aside from `test`, `images` does build the jar.
>
>     When an IDE running on JDK X needs to build/run a project for
>     target JDK Y then it will use the jrt file system to access the
>     classes in the target JDK. jrt-fs.jar is the provider
>     implementation that JDK X will load to do this.
>
>
> If the jar does not mean, seems like an exploded image jdk won't work 
> for ^?

jrtfs provides access, via the file system API and provider mechanism, 
to the classes/resources in the "current" run-time image. It handles 
exploded builds and images builds.

jrtfs also provides access to the classes/resources in a remote/target 
JDK, think IDE running on JDK $X but targeting JDK $Y. Creating a jrtfs 
file system on JDK $X with home=JDK $Y will load the file system 
proivider from JDK $Y jrt-fs.jar. This is why the classes in jrt-fs.jar 
are compiled --release 8.

I think you are asking why the exploded build doesn't include 
jrt-fs.jar. I suppose it could but the exploded build is just an interim 
step in the JDK build and not something that a vendor would ship. If 
there were a strong need for an IDE running on JDK $X to target an 
exploded build of JDK $Y then it can be made it work but it seems a less 
interesting setup.

Hopefully it is starting to be clear that jrt-fs.jar is not tied to 
testing the JDK, it is needed in an images build to support IDEs (and 
other tools) that target the JDK.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250401/da5a5faa/attachment.htm>

From ihse at openjdk.org  Tue Apr  1 08:48:08 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 08:48:08 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64
In-Reply-To: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
Message-ID: <ABpQrvjrFY0kpq21Q0qYARJWz-h-Wj65Vtbn4SHc5DM=.d8bbbbce-1c35-4b7e-9112-1433b61a69db@github.com>

On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
> 
> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
> 
> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
> 
> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
> 
> Testing: hs-tier1 - hs-tier4, microbenchmarks

The rule that has dictated placement of the sources is where it is actually used in the JDK. If upstream spleef is cross-platform, or if the generated code is platform independent is strictly speaking irrelevant, if it is only used in our linux builds.

Unless you are like 95% sure you are going to use libsleef on Windows, I still think it should be put in unix rather than share. Moving it once again is not that much of a hassle. 

In contrast, if we in general allowed ourselves to not keep the source code based on what we do, but "just as a precaution if we are going to do stuff in the future", it would be much harder to reason about the code. This is a sort of "tragedy of the commons" -- every single piece of code might think that "this extra but unnecessary generalization helps me a bit and does not hurt much", but if you let that sentiment guide your code it quickly becomes much harder to maintain than necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2768632094

From ihse at openjdk.org  Tue Apr  1 08:57:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 08:57:02 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64
In-Reply-To: <kWlbRA-3wKX2o3QmKF0Y_XGjkBbTptNIXmct8VMrBIY=.f3603471-8729-4f44-83a3-6a80446b0d77@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <b_cgE7zSlhl4Xn4tKbO1YVfg1acSSYbYObzmDuAMoMY=.ad0a5d22-9cff-4d35-a292-37a3e73a0035@github.com>
 <kWlbRA-3wKX2o3QmKF0Y_XGjkBbTptNIXmct8VMrBIY=.f3603471-8729-4f44-83a3-6a80446b0d77@github.com>
Message-ID: <eiP_IszVBTwMLq-8WbcZjVa00tWRLaZbHrv_YU12uYU=.a75200bd-1fd6-4dd7-b954-419379a9a978@github.com>

On Mon, 31 Mar 2025 21:53:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > That commit assumes that vector_math_sve.c should have $(SVE_CFLAGS) on mac as well as on linux. If that is not correct, then it needs to be adjusted.
> 
> As of now, Apple Silicon doesn't support SVE/SVE2, so I intentionally excluded SVE support on macosx-aarch64. What would be the best way to exclude `vector_math_sve.c` on macosx-aarch64?

The best way would be to make sure SVE_CFLAGS is empty on macosx.


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index 73786587735..6e5a70a43a5 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -924,8 +924,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
   # Check whether the compiler supports the Arm C Language Extensions (ACLE)
   # for SVE. Set SVE_CFLAGS to -march=armv8-a+sve if it does.
   # ACLE and this flag are required to build the aarch64 SVE related functions in
-  # libvectormath.
-  if test "x$OPENJDK_TARGET_CPU" = "xaarch64"; then
+  # libvectormath. Apple Silicon does not support SVE; use macOS as a proxy for
+  # that check.
+  if test "x$OPENJDK_TARGET_CPU" = "xaarch64" && test "x$OPENJDK_TARGET_OS" = "xlinux"; then
     if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
       AC_LANG_PUSH(C)
       OLD_CFLAGS="$CFLAGS"

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2768656092

From harald+jdklists at volse.no  Tue Apr  1 10:31:06 2025
From: harald+jdklists at volse.no (Harald Eilertsen)
Date: Tue, 1 Apr 2025 12:31:06 +0200
Subject: Posted a couple of JBS issues
Message-ID: <a427od2qbos7gqkkbxs3v75njxd63ir72vv3l7ibxr6lprg22h@jrcyfglreuhk>

Hi,

I tries posting a couple of issues via the bugreport tool for some minor
enhancements to the build system and configure scripts.

These are:

* libjpeg not found if not in system directories (internal ID 9078307)
* Giflib not found when not in system directories (internal ID 9078316)

Not sure if I managed to classify them correctly, didn't really find any
categories that looked fitting.

In any case, if anybody could have a look and accept the issues, I could
submit the patches for review.

Thanks in advance!

Harald Eilertsen
--
Eilertsens Kodeknekkeri
https://kodeknekkeriet.net

From jlahoda at openjdk.org  Tue Apr  1 11:22:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Apr 2025 11:22:22 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
Message-ID: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>

On Mon, 31 Mar 2025 17:22:45 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75:
> 
>> 73:                     }
>> 74:                     continue READ;
>> 75:                 case '\033':
> 
> If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right?

In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind?

(*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2022656839

From ihse at openjdk.org  Tue Apr  1 11:50:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 11:50:18 GMT
Subject: Integrated: 8353272: One instance of STATIC_LIB_CFLAGS was missed in
 JDK-8345683
In-Reply-To: <5UuTTHeKv6t_TKqoEORD5lWto_glgrsDZDJKsY0EK5M=.70e0fc2a-b364-4e77-89b4-6a5fc5d78e9e@github.com>
References: <5UuTTHeKv6t_TKqoEORD5lWto_glgrsDZDJKsY0EK5M=.70e0fc2a-b364-4e77-89b4-6a5fc5d78e9e@github.com>
Message-ID: <HFsNJW7BRsSnvrSnQJ12SidnN1pRSxDV_IcBLwCaJGs=.55b04988-ac4a-466d-9163-6053565d12b2@github.com>

On Mon, 31 Mar 2025 13:27:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It turns out one instance of STATIC_LIB_CFLAGS was missed in Flags.gmk when fixing [JDK-8345683](https://bugs.openjdk.org/browse/JDK-8345683). This was noticed by @cnqpzhang in https://github.com/openjdk/jdk/pull/24115/files#r2011164138.

This pull request has now been integrated.

Changeset: cef5610b
Author:    Patrick Zhang <qpzhang at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cef5610b5d4f7c5c2ceda46995ef3a0d961294e5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Tue Apr  1 11:50:29 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 11:50:29 GMT
Subject: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM
 src/hotspot C++ source files [v4]
In-Reply-To: <nT6MwxltFM8gdqpyOpX9nYMjMXz4uAmwHQGjylMMjM8=.daaf5938-9b02-41ac-b379-48b98c417d86@github.com>
References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com>
 <nT6MwxltFM8gdqpyOpX9nYMjMXz4uAmwHQGjylMMjM8=.daaf5938-9b02-41ac-b379-48b98c417d86@github.com>
Message-ID: <AtcP9ziADz-vtGCwjjJHz38kvgx_4MeelKw_jJAIXG4=.fdfa9add-fcbc-4790-8426-eae71a549c1b@github.com>

On Mon, 31 Mar 2025 14:31:56 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. 
>> 
>> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`.
>> 
>> This PR does:
>> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected.
>> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`.
>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs.
>> 
>> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks.
>
> Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272
>   
>   Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2769092442

From qpzhang at openjdk.org  Tue Apr  1 11:50:29 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Tue, 1 Apr 2025 11:50:29 GMT
Subject: Integrated: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM
 src/hotspot C++ source files
In-Reply-To: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com>
References: <0Xq3P84bNuYMCVaX9i8IfAInlWxQVrxDD3yIcI_T_8w=.9cc9cd31-5658-4e85-ab6c-851b5389bce3@github.com>
Message-ID: <DVyZz9Q6PxjHjngQg8ZmII-yHedx-v7MeVdT1W3UUY0=.21867b06-e666-4ac2-8a39-755ae9fee6db@github.com>

On Wed, 19 Mar 2025 14:43:28 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` triggers 1000+ warning messages like `cc1plus: warning: command-line option ?-Wno-incompatible-pointer-types? is valid for C/ObjC but not for C++`. 
> 
> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building `BUILD_LIBJVM`.
> 
> This PR does:
> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected.
> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch should not be compiled with `EXTRA_CFLAGS`.
> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was missed by [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) for the refactor of building static libs.
> 
> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, also passed OpenJDK GHA Sanity Checks.

This pull request has now been integrated.

Changeset: 1809138b
Author:    Patrick Zhang <qpzhang at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1809138b1c992b352eceab3e0e963b0577aafabb
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Tue Apr  1 11:54:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 11:54:17 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64
In-Reply-To: <JSvnclMxp335_sO5ReY4_cRTq9EkTHQWEOVYPfRRkuI=.e68f372c-ce86-4698-885f-81557ee89961@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <JSvnclMxp335_sO5ReY4_cRTq9EkTHQWEOVYPfRRkuI=.e68f372c-ce86-4698-885f-81557ee89961@github.com>
Message-ID: <3t_wc5_YstX1OvL-QywjwWxard8Da4qisWUEh4qAJ4M=.b6a72c38-b3b3-4f64-a5d5-a20363153b91@github.com>

On Sat, 29 Mar 2025 17:46:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> That would implicitly mean to any developers that it's shared code for all currently supported operating systems: Windows, macOS, Linux and AIX, which may be rather confusing if it's only meant to be used on specific platforms.

@TheShermanTanker To clarify, the `share` directory does not imply that the code within is used on *all* platform, only that it is shared on *some* platform, and no more specific home was possible. There are a lot of code all over the place in `share` that are excluded from one or another platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2769101099

From ihse at openjdk.org  Tue Apr  1 11:56:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 11:56:32 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v3]
In-Reply-To: <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
Message-ID: <Xf3KKR6hkhOSMPOaECC_O03AvBuRmtypHih5QTnLS6g=.c3c00243-cf63-4483-830e-7934f2babed9@github.com>

On Mon, 31 Mar 2025 18:11:27 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add instructions for a native Windows AArch64 build

I propose we hold off pushing this PR for at least a while, while we investigate how easy or hard it is to fix JDK-8353066. It is magnitudes better to fix so configure works automatically, than trying to document broken behavior and workarounds. (No-one read the documentation anyway... :-/)

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2769107942

From ihse at openjdk.org  Tue Apr  1 12:02:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 12:02:19 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

It would be interesting to also see how compilation times varies with optimization level. At least some kind of hint if HIGHEST is like 2x slower than LOW, or if SIZE is slower than LOW at all, etc. The relative speed difference is interesting, but so is it in absolute terms. If a library takes 0.5 seconds on LOW but 1.1 seconds on HIGH on a particular system, it is unlikely to matter much to overall build time anywhere. But if it goes from 15s to 30s on a fast machine, it might be a problem if such performance regressions stack up, especially on slower machines (which includes the ones running GHA).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2769121979

From syan at openjdk.org  Tue Apr  1 12:07:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Apr 2025 12:07:09 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0 [v3]
In-Reply-To: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
Message-ID: <d8GPWamWTeY90MeZ5m_0fmojWqi7WNeOw1atDpdpWq8=.fdd902ba-f13b-4bcc-a845-962f988f3996@github.com>

> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
> 
> 
>> cat java.c
> char a() {
>   return 0;
>   int b;
>   if (a(&b))
>     return 0;
> }
> 
>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
> java.c: In function ?a?:
> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>     6 | }
>       | ^
> cc1: all warnings being treated as errors

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

  add "#if defined(__GNUC__)" to fix windows build warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24318/files
  - new: https://git.openjdk.org/jdk/pull/24318/files/83beb975..8d929c8d

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

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

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

From dholmes at openjdk.org  Tue Apr  1 12:58:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Apr 2025 12:58:56 GMT
Subject: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed
 in JDK-8345683
Message-ID: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>

Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"

This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.

This causes failures building the static libs on Windows and macOS.

Thanks

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

Commit messages:
 - Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"

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

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

From alanb at openjdk.org  Tue Apr  1 12:58:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Apr 2025 12:58:56 GMT
Subject: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was
 missed in JDK-8345683
In-Reply-To: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
References: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
Message-ID: <0D3llOoaau_4gydoeG07XTp0IyoqC3iYa9FhavmnVjs=.e42976d3-e665-453e-8be6-864f6730a343@github.com>

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
> 
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
> 
> This causes failures building the static libs on Windows and macOS.
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24356#pullrequestreview-2732571342

From dholmes at openjdk.org  Tue Apr  1 13:02:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Apr 2025 13:02:17 GMT
Subject: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was
 missed in JDK-8345683
In-Reply-To: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
References: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
Message-ID: <hS4_HI2IirFD-jdvJSBwGwQdDzbOw30M_xXY8rvgQqw=.f144665d-a45c-4e9b-b662-351dbbebc27f@github.com>

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
> 
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
> 
> This causes failures building the static libs on Windows and macOS.
> 
> Thanks

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24356#issuecomment-2769278657

From ihse at openjdk.org  Tue Apr  1 13:02:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 13:02:16 GMT
Subject: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was
 missed in JDK-8345683
In-Reply-To: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
References: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
Message-ID: <G-nHOuf0kOhdOHu6dwPPIqfCHi8kXjdY3uY0QjY2ISk=.a6610229-5975-4e16-8a16-5b882ccab4a3@github.com>

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
> 
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
> 
> This causes failures building the static libs on Windows and macOS.
> 
> Thanks

LGTM. Sorry for the mess. ?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24356#pullrequestreview-2732606027

From dholmes at openjdk.org  Tue Apr  1 13:02:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Apr 2025 13:02:17 GMT
Subject: Integrated: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was
 missed in JDK-8345683
In-Reply-To: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
References: <-RAipLCyvjjNCX1dA25cgpam5qultfEE3LfIhVZRUrk=.2578c11d-42de-4e95-bd08-7237272a712e@github.com>
Message-ID: <y3cd8JbS-gMN-CVG7EVmBke_Rcz0ZK0_iTfx5d9D3x0=.c40235d0-5bf5-445a-8a1d-5c97d98c5bbb@github.com>

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
> 
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
> 
> This causes failures building the static libs on Windows and macOS.
> 
> Thanks

This pull request has now been integrated.

Changeset: a1ab1d8d
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1ab1d8de411aace21decd133e7e74bb97f27897
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

Reviewed-by: alanb, ihse

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

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

From ihse at openjdk.org  Tue Apr  1 13:29:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 13:29:17 GMT
Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
Message-ID: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>

The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang.

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

Commit messages:
 - 8353458: Don't pass -Wno-format-nonliteral to CFLAGS

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

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

From duke at openjdk.org  Tue Apr  1 14:26:48 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 1 Apr 2025 14:26:48 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
 <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>
Message-ID: <HSMApPaJ2LeG91zr6lt3AV9760v3lMLEgonwtEp_Mjg=.87e1e4b4-4070-4b93-93d8-0abf36cf82cd@github.com>

On Tue, 1 Apr 2025 11:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75:
>> 
>>> 73:                     }
>>> 74:                     continue READ;
>>> 75:                 case '\033':
>> 
>> If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right?
>
> In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind?
> 
> (*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that.

I suppose I don't have a particular terminal in mind. But at the very least, maybe some documentation somewhere should reference e.g. [ECMA-48](https://ecma-international.org/publications-and-standards/standards/ecma-48/) as the basis for the behaviors of the console?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2022971819

From mbaesken at openjdk.org  Tue Apr  1 14:51:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Apr 2025 14:51:47 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <hkkzLFBIjTkZyS4kxP-vEqpyCPDd_Dsfr_n6VVCf7T4=.c0c190a3-ff90-4f60-8e3a-beab09d41047@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <J_8wxlogNNI5saILAk3poNptc5KleCXpp-_guh6XMOs=.e6ffad72-061b-4b29-87fc-a1eba23c4926@github.com>
 <Ha92pH4GssvfTlJYI_SIpqfKbNcBMfNrKh3nyflmS2w=.8632639c-39bb-4d7c-a6f1-a0ab3e23a17c@github.com>
 <rFvynxnkeMv2a00pq2CptrM1mn4biKRa4YOhhMDjS4Y=.a0c429bc-2fec-49d4-8f62-ce5ab1928162@github.com>
 <hkkzLFBIjTkZyS4kxP-vEqpyCPDd_Dsfr_n6VVCf7T4=.c0c190a3-ff90-4f60-8e3a-beab09d41047@github.com>
Message-ID: <1JwtxX-_wpEi7pu8DRZfclDGx9DjR4lO3ySAt9JsYoQ=.41a275a5-0e91-4118-9bc3-e278eacf3aca@github.com>

On Mon, 31 Mar 2025 13:09:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> but what happens if you replace both instances of -fuse-linker-plugin with -fno-use-linker-plugin on Linux in JvmFeatures.gmk
Then the compilation fails when lto is configured with this message 

cc1plus: error: '-fno-fat-lto-objects' are supported only with linker plugin

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2769633581

From mbaesken at openjdk.org  Tue Apr  1 15:21:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Apr 2025 15:21:52 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <hSv3oVaP-ciRushkg3nMZwjVHxY2QII7ER7jAWGFsNw=.b7df703a-dfbc-42fa-a63f-14bb39f27e7f@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/2c3c6c41...9d05cb8e

When setting -fno-use-linker-plugin  and removing also  -fno-fat-lto-objects , the error above goes away.
but we get a ton of other errors


src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:663: error: undefined reference to 'G1NUMA::is_enabled() const'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:667: error: undefined reference to 'G1NUMA::num_active_nodes() const'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:669: error: undefined reference to 'AllocateHeap(unsigned long, MemTag, AllocFailStrategy::AllocFailEnum)'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:116: error: undefined reference to 'G1RedirtyCardsLocalQueueSet::flush()'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:677: error: undefined reference to 'G1NUMA::index_of_current_thread() const'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:678: error: undefined reference to 'G1NUMA::copy_statistics(G1NUMAStats::NodeDataItems, unsigned int, unsigned long*)'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:119: error: undefined reference to 'G1PLABAllocator::flush_and_retire_stats(unsigned int)'
src/hotspot/share/gc/g1/g1Policy.hpp:427: error: undefined reference to 'AgeTable::merge(AgeTable const*)'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:123: error: undefined reference to 'G1NewTracer::report_evacuation_failed(EvacuationFailedInfo&)'
src/hotspot/share/gc/g1/g1Allocator.inline.hpp:116: error: undefined reference to 'G1PLABAllocator::allocate_direct_or_new_plab(G1HeapRegionAttr, unsigned long, bool*, unsigned int)'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:384: error: undefined reference to 'G1PLABAllocator::allocate_direct_or_new_plab(G1HeapRegionAttr, unsigned long, bool*, unsigned int)'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:397: error: undefined reference to 'YoungGCTracer::should_report_promotion_events() const'
src/hotspot/share/gc/g1/g1Allocator.inline.hpp:116: error: undefined reference to 'G1PLABAllocator::allocate_direct_or_new_plab(G1HeapRegionAttr, unsigned long, bool*, unsigned int)'
src/hotspot/share/gc/shared/cardTable.hpp:184: error: undefined reference to 'CardTable::_card_size'
src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:126: error: undefined reference to 'G1HeapRegion::LogOfHRGrainBytes'
src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:79: error: undefined reference to 'G1Policy::phase_times() const'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:143: error: undefined reference to 'G1PLABAllocator::waste() const'
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:147: error: undefined reference to 'G1PLABAllocator::undo_waste() const'


and


src/hotspot/os/linux/mallocInfoDcmd.cpp: In member function 'execute':
src/hotspot/os/linux/mallocInfoDcmd.cpp:57:3: warning: call to 'free' declared with attribute warning: use os::free [-Wattribute-warning]
In member function '__dt_base ',
    inlined from 'c2v_getLocalVariableTableLength' at src/hotspot/share/jvmci/jvmciCompilerToVM.cpp:1348:1:
src/hotspot/share/jvmci/jvmciEnv.cpp:615:5: warning: call to 'free' declared with attribute warning: use os::free [-Wattribute-warning]
In member function '__dt_base ',
    inlined from 'c2v_getCountersSize' at src/hotspot/share/jvmci/jvmciCompilerToVM.cpp:1403:1:
src/hotspot/share/jvmci/jvmciEnv.cpp:615:5: warning: call to 'free' declared with attribute warning: use os::free [-Wattribute-warning]
In member function '__dt_base ',
    inlined from 'c2v_setCountersSize' at src/hotspot/share/jvmci/jvmciCompilerToVM.cpp:1407:1:
src/hotspot/share/jvmci/jvmciEnv.cpp:615:5: warning: call to 'free' declared with attribute warning: use os::free [-Wattribute-warning]
In member function '__dt_base ',
    inlined from 'c2v_isMature' at src/hotspot/share/jvmci/jvmciCompilerToVM.cpp:1425:1:
src/hotspot/share/jvmci/jvmciEnv.cpp:615:5: warning: call to 'free' declared with attribute warning: use os::free [-Wattribute-warning]
In member function '__dt_base ',
   ... (rest of output omitted)


(some examples) ; so this does not work (at least with gcc-14) .

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2769734227

From erikj at openjdk.org  Tue Apr  1 15:46:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 1 Apr 2025 15:46:17 GMT
Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
In-Reply-To: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
References: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
Message-ID: <jdDxGZxW0AjAGS-Sc5Q6wEKuVb3K4PODaQarJAFpRwU=.0eeb8b37-eb84-481f-ad72-2ffedb5e67c2@github.com>

On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24357#pullrequestreview-2733182097

From mikael at openjdk.org  Tue Apr  1 18:26:25 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 1 Apr 2025 18:26:25 GMT
Subject: RFR: 8342984: Bump minimum boot jdk to JDK 24
In-Reply-To: <fYFfshn30CH86Hrpokpxf3Mg9uIYlJucwcAPK_-qXj4=.3db6fbb7-85f6-4eed-a9f1-a292d2d87ccd@github.com>
References: <fYFfshn30CH86Hrpokpxf3Mg9uIYlJucwcAPK_-qXj4=.3db6fbb7-85f6-4eed-a9f1-a292d2d87ccd@github.com>
Message-ID: <Vvwz4dxuUWpuLk1Dk452oRky1Q7Mx876JGEn8pJdsl4=.96a899d0-3388-4700-9184-5e62a538e75e@github.com>

On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24305#issuecomment-2770332790

From mikael at openjdk.org  Tue Apr  1 18:26:26 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 1 Apr 2025 18:26:26 GMT
Subject: Integrated: 8342984: Bump minimum boot jdk to JDK 24
In-Reply-To: <fYFfshn30CH86Hrpokpxf3Mg9uIYlJucwcAPK_-qXj4=.3db6fbb7-85f6-4eed-a9f1-a292d2d87ccd@github.com>
References: <fYFfshn30CH86Hrpokpxf3Mg9uIYlJucwcAPK_-qXj4=.3db6fbb7-85f6-4eed-a9f1-a292d2d87ccd@github.com>
Message-ID: <ckLzSP9VQD9MvU8mfp0u9ZwhY4XWZRUNLCp4URkaDec=.346c5cb0-3896-4148-971b-24bbaa053f2b@github.com>

On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> With the JDK 24 GA out it's time to bump the minimum boot JDK version for mainline/JDK 25.
> 
> Testing: tier1-5, GHA

This pull request has now been integrated.

Changeset: 07fd666d
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07fd666d998cd8a485012eac4fab11b7e0f909d3
Stats:     14 lines in 3 files changed: 0 ins; 0 del; 14 mod

8342984: Bump minimum boot jdk to JDK 24

Reviewed-by: iris, darcy, liach, ihse

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

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

From vlivanov at openjdk.org  Tue Apr  1 19:59:20 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Apr 2025 19:59:20 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v2]
In-Reply-To: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
Message-ID: <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>

> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
> 
> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
> 
> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
> 
> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
> 
> Testing: hs-tier1 - hs-tier4, microbenchmarks

Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Build changes
 - share/native -> unix/native

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24306/files
  - new: https://git.openjdk.org/jdk/pull/24306/files/108cc0c3..90312182

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

  Stats: 67 lines in 175 files changed: 14 ins; 32 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/24306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24306/head:pull/24306

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

From vlivanov at openjdk.org  Tue Apr  1 20:03:43 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Apr 2025 20:03:43 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v2]
In-Reply-To: <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
Message-ID: <BVg6bYUl2I86XpBbfOBpzHe2PSGb-0inEpDNoDju1Ok=.a9778ae8-4dcf-44a9-9f03-404ffc4dd2a8@github.com>

On Tue, 1 Apr 2025 19:59:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
>> 
>> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
>> 
>> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
>> 
>> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
>> 
>> Testing: hs-tier1 - hs-tier4, microbenchmarks
>
> Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Build changes
>  - share/native -> unix/native

Thanks, Magnus. I incorporated your patches into the PR. The library code is now located under `src/jdk.incubator.vector/unix/native/libsleef`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2770548994

From ihse at openjdk.org  Tue Apr  1 21:09:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 21:09:17 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v2]
In-Reply-To: <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
Message-ID: <gWzRTXdNU60QwDLaXj_WC5jwDTVfa88RFBV2cPwlc3c=.d3a03049-4197-4a07-86c2-1de3077d0962@github.com>

On Tue, 1 Apr 2025 19:59:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
>> 
>> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
>> 
>> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
>> 
>> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
>> 
>> Testing: hs-tier1 - hs-tier4, microbenchmarks
>
> Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Build changes
>  - share/native -> unix/native

LGTM now. Thanks! I sauggest awaiting another build group reviewer since I wrote some of this code.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24306#pullrequestreview-2734048599

From ihse at openjdk.org  Tue Apr  1 21:12:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 21:12:14 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0 [v3]
In-Reply-To: <d8GPWamWTeY90MeZ5m_0fmojWqi7WNeOw1atDpdpWq8=.fdd902ba-f13b-4bcc-a845-962f988f3996@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
 <d8GPWamWTeY90MeZ5m_0fmojWqi7WNeOw1atDpdpWq8=.fdd902ba-f13b-4bcc-a845-962f988f3996@github.com>
Message-ID: <itJhFp96klKQ335oo7DIAmM9Gz_cqsX9OlpfX6cFszo=.152945a5-949b-47a9-b9e1-eb19e10775bf@github.com>

On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
>> 
>> 
>>> cat java.c
>> char a() {
>>   return 0;
>>   int b;
>>   if (a(&b))
>>     return 0;
>> }
>> 
>>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
>> java.c: In function ?a?:
>> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>>     6 | }
>>       | ^
>> cc1: all warnings being treated as errors
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add "#if defined(__GNUC__)" to fix windows build warning

LGTM.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24318#pullrequestreview-2734052946

From erikj at openjdk.org  Tue Apr  1 22:14:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 1 Apr 2025 22:14:22 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v2]
In-Reply-To: <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
Message-ID: <EijdyI7PNBXOvB5KlPub_3Am4ZhtoZb15YGwrLjYk68=.e237fdeb-9862-4c1e-9651-a7db25229da8@github.com>

On Tue, 1 Apr 2025 19:59:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
>> 
>> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
>> 
>> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
>> 
>> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
>> 
>> Testing: hs-tier1 - hs-tier4, microbenchmarks
>
> Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Build changes
>  - share/native -> unix/native

src/jdk.incubator.vector/unix/native/libsleef/README.md line 13:

> 11: 
> 12: The upstream original source code is available in
> 13: `src/jdk.incubator.vector/share/native/libsleef/upstream`. However, this code is

share -> unix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2023742031

From vlivanov at openjdk.org  Tue Apr  1 22:45:09 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Apr 2025 22:45:09 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v3]
In-Reply-To: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
Message-ID: <F1iz2ONjUyctf1Vcq8MkM3B9qBJFrDm7LR8sm3PLuVc=.038e2c91-79e7-4bcf-8fdf-b21a9d4f5190@github.com>

> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
> 
> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
> 
> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
> 
> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
> 
> Testing: hs-tier1 - hs-tier4, microbenchmarks

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

  Adjust README.md

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24306/files
  - new: https://git.openjdk.org/jdk/pull/24306/files/90312182..8ac5d0bb

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

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

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

From vlivanov at openjdk.org  Tue Apr  1 22:45:11 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Apr 2025 22:45:11 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v2]
In-Reply-To: <EijdyI7PNBXOvB5KlPub_3Am4ZhtoZb15YGwrLjYk68=.e237fdeb-9862-4c1e-9651-a7db25229da8@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <hXE3zuOGOlG-gipjzHaNSzTwFLC3t2wSXUFRCF5Uu4c=.9434f0de-3a22-43ec-9ee3-f505757f9baf@github.com>
 <EijdyI7PNBXOvB5KlPub_3Am4ZhtoZb15YGwrLjYk68=.e237fdeb-9862-4c1e-9651-a7db25229da8@github.com>
Message-ID: <0rbzz5vo1TGUjZlYXaBYT-bMUBoZn7no8fQrRtfCcXg=.2c61c27d-3957-4e9d-80b9-51a98c6ff275@github.com>

On Tue, 1 Apr 2025 22:09:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Build changes
>>  - share/native -> unix/native
>
> src/jdk.incubator.vector/unix/native/libsleef/README.md line 13:
> 
>> 11: 
>> 12: The upstream original source code is available in
>> 13: `src/jdk.incubator.vector/share/native/libsleef/upstream`. However, this code is
> 
> share -> unix

Good catch. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2023765350

From erikj at openjdk.org  Tue Apr  1 23:04:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 1 Apr 2025 23:04:11 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v3]
In-Reply-To: <F1iz2ONjUyctf1Vcq8MkM3B9qBJFrDm7LR8sm3PLuVc=.038e2c91-79e7-4bcf-8fdf-b21a9d4f5190@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <F1iz2ONjUyctf1Vcq8MkM3B9qBJFrDm7LR8sm3PLuVc=.038e2c91-79e7-4bcf-8fdf-b21a9d4f5190@github.com>
Message-ID: <DSiQkbC5CMH2JCWF4nMxJJZcP3j4kEPGAXzj08QZsPY=.e0dc61e5-dc9b-4c0e-a138-1c63516370be@github.com>

On Tue, 1 Apr 2025 22:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
>> 
>> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
>> 
>> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
>> 
>> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
>> 
>> Testing: hs-tier1 - hs-tier4, microbenchmarks
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust README.md

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24306#pullrequestreview-2734208521

From dholmes at openjdk.org  Wed Apr  2 02:04:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Apr 2025 02:04:09 GMT
Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
In-Reply-To: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
References: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
Message-ID: <vcAJosuSI2SC0Ok8K0V0OQmIqUWWEf3HNKzk9bI-sSc=.13be64c9-eef0-4728-ae11-7b97082f8f41@github.com>

On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> there was already a pragma but due to incorrect restrictions it did not apply to clang.

How does the `__GNUC__` check affect clang?? Isn't that just for gcc?

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

PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771087761

From jwaters at openjdk.org  Wed Apr  2 07:25:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Apr 2025 07:25:19 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0 [v3]
In-Reply-To: <d8GPWamWTeY90MeZ5m_0fmojWqi7WNeOw1atDpdpWq8=.fdd902ba-f13b-4bcc-a845-962f988f3996@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
 <d8GPWamWTeY90MeZ5m_0fmojWqi7WNeOw1atDpdpWq8=.fdd902ba-f13b-4bcc-a845-962f988f3996@github.com>
Message-ID: <oWWVV_xym4zm8wonV_-Q130MqpidkP8Q8I6xIWPvAtI=.a483cbbd-653d-4f19-9b31-d2a0841d5814@github.com>

On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
>> 
>> 
>>> cat java.c
>> char a() {
>>   return 0;
>>   int b;
>>   if (a(&b))
>>     return 0;
>> }
>> 
>>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
>> java.c: In function ?a?:
>> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>>     6 | }
>>       | ^
>> cc1: all warnings being treated as errors
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add "#if defined(__GNUC__)" to fix windows build warning

I was going to suggest adding an && condition checking for ! __clang__ in the #if, but after some thinking I think it is not worth the trouble to add that. This looks good to go

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24318#pullrequestreview-2734896635

From shade at openjdk.org  Wed Apr  2 07:29:25 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Apr 2025 07:29:25 GMT
Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4]
In-Reply-To: <d7y5WjS6GLjV2lnMbAWOoPwpl_OaYeEFhz58SwCFjQE=.c5946b8d-b23d-49dc-aeca-bf962212bbbb@github.com>
References: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
 <d7y5WjS6GLjV2lnMbAWOoPwpl_OaYeEFhz58SwCFjQE=.c5946b8d-b23d-49dc-aeca-bf962212bbbb@github.com>
Message-ID: <ymOPwwBjNxvZhjmYztxQLlsN1PSc1hU6AyNqgVN2Las=.a0e9bda7-bc12-4052-8c6f-e2b620b83382@github.com>

On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A simple fix in `os::jvm_path()` so that gtest can be run with CDS (`-Xshare:on`). The fix is just to change the directory name from `hotspot` to `server`.
>> Note that the bug doesn't exist on macOS and thus no change is required for `os_bsd.cpp`.
>> 
>> Testing:
>> 
>> - run gtest with -Xshare:on on linux-x64
>> - tier1
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @magius and @iklam comments

Well, this apparently broke CDS archive generation / use in my multi-JVM builds. Looking for CDS archives in vicinity of currently launched libjvm.so is a feature that got unfortunately broken by this. Filed: https://bugs.openjdk.org/browse/JDK-8353504

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

PR Comment: https://git.openjdk.org/jdk/pull/23758#issuecomment-2771575425

From jwaters at openjdk.org  Wed Apr  2 08:03:32 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Apr 2025 08:03:32 GMT
Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
In-Reply-To: <vcAJosuSI2SC0Ok8K0V0OQmIqUWWEf3HNKzk9bI-sSc=.13be64c9-eef0-4728-ae11-7b97082f8f41@github.com>
References: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
 <vcAJosuSI2SC0Ok8K0V0OQmIqUWWEf3HNKzk9bI-sSc=.13be64c9-eef0-4728-ae11-7b97082f8f41@github.com>
Message-ID: <oeERUsPjJFgyVL-X4CUEhqczkRXqNHhckoDSMx8o8_E=.e797ebbc-0996-4fd0-9ea7-26890881c29d@github.com>

On Wed, 2 Apr 2025 02:00:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > there was already a pragma but due to incorrect restrictions it did not apply to clang.
> 
> How does the `__GNUC__` check affect clang?? Isn't that just for gcc?

clang has a tendency to like to pretend to be other compilers, it defines __GNUC__ in addition to __clang__ and even defines _MSC_VER if you're compiling for Windows. This is why it's common in code to see the #ifdef __clang__ be the very first ifdef when checking for a compiler; It has to be first, otherwise the check wouldn't work. If I had to guess, while clang defines __GNUC__ it doesn't define it to the version number like gcc does, which is why the > 5 check failed in clang's case here

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

PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771672196

From syan at openjdk.org  Wed Apr  2 08:29:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Apr 2025 08:29:23 GMT
Subject: Integrated: 8304674: File java.c compile error with -fsanitize=address
 -O0
In-Reply-To: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
Message-ID: <sEq7G5qW1VCO7wk44cMbmgwqhAsu7XD8PXEXP-VNePY=.2b217131-0bd0-4f87-8143-bde63b1b4428@github.com>

On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
> 
> 
>> cat java.c
> char a() {
>   return 0;
>   int b;
>   if (a(&b))
>     return 0;
> }
> 
>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
> java.c: In function ?a?:
> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>     6 | }
>       | ^
> cc1: all warnings being treated as errors

This pull request has now been integrated.

Changeset: 9076673d
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9076673d7df3c20bdb6e7fdf253030bc19a3d9dc
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8304674: File java.c compile error with -fsanitize=address -O0

Reviewed-by: ihse, jwaters

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

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

From syan at openjdk.org  Wed Apr  2 08:29:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Apr 2025 08:29:23 GMT
Subject: RFR: 8304674: File java.c compile error with -fsanitize=address
 -O0
In-Reply-To: <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com>
References: <hBU_hanI6BU0ETybzeOJOb3T5lTiWUPc_51zksUsco4=.7090a900-c3d6-417a-abfe-847ec0f19d3f@github.com>
 <5XLdWLua54uHwdnZst3xc89s1ipMJijjEEWvN8jHavc=.d70404aa-ab13-4e91-ab42-aa173516b07e@github.com>
Message-ID: <aW471KfGBWwFqka5Ay6Xk2ysRCcCmeB0Vmw5Ci4brsY=.3ca2abb5-68d5-4757-b848-32082f764891@github.com>

On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches end of non-void function [-Werror=return-type] with gcc options -fsanitize=address -O0. The function int JavaMain(void* _args) in this file will execute return ret in LEAVE() macro, but gcc with -O0 is not smart enough to recognized that the function already has return statement before at the end of function. It's a gcc bug which has been recorded by [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code snippet can demonstrate the gcc bug. I think we should disable return-type gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
>> 
>> 
>>> cat java.c
>> char a() {
>>   return 0;
>>   int b;
>>   if (a(&b))
>>     return 0;
>> }
>> 
>>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
>> java.c: In function ?a?:
>> java.c:6:1: error: control reaches end of non-void function [-Werror=return-type]
>>     6 | }
>>       | ^
>> cc1: all warnings being treated as errors
>
> While I normally advocate using DISABLE_WARNING in makefiles instead of pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro would be better?

Thanks for the reviews @magicus @TheShermanTanker

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

PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2771787344

From ihse at openjdk.org  Wed Apr  2 09:50:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 09:50:53 GMT
Subject: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
In-Reply-To: <oeERUsPjJFgyVL-X4CUEhqczkRXqNHhckoDSMx8o8_E=.e797ebbc-0996-4fd0-9ea7-26890881c29d@github.com>
References: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
 <vcAJosuSI2SC0Ok8K0V0OQmIqUWWEf3HNKzk9bI-sSc=.13be64c9-eef0-4728-ae11-7b97082f8f41@github.com>
 <oeERUsPjJFgyVL-X4CUEhqczkRXqNHhckoDSMx8o8_E=.e797ebbc-0996-4fd0-9ea7-26890881c29d@github.com>
Message-ID: <uDAFXHZhg5p26GafjS-UUBZvP9bLPPdvowCJwKiKfj4=.3dd1354e-255c-4e7d-a23c-07195809008f@github.com>

On Wed, 2 Apr 2025 08:00:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> How does the __GNUC__ check affect clang?? Isn't that just for gcc?

No, clang disguises as gcc in several ways, and this is one of them. In effect, you can consider `__GNUC__` to be not a check for a particular compiler, but for compliance with the "standard" that gcc defined.

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

PR Comment: https://git.openjdk.org/jdk/pull/24357#issuecomment-2771978347

From ihse at openjdk.org  Wed Apr  2 09:50:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 09:50:58 GMT
Subject: Integrated: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS
In-Reply-To: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
References: <mUqnPio_P2v9FbptSap4uoEzr7GabRx9YRGlmgzjtU4=.6d374e23-ff03-434d-ae8d-d5bdf4ccd593@github.com>
Message-ID: <dlaDZlYobFLzWViXEU0NajwMIs_09ToizL19MQCjI3g=.eaa0c6e0-0dc1-46ce-a3fb-3c8a4a572659@github.com>

On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The proper way to disable warnings is to use the DISABLED_WARNINGS arguments. In this particular case, there was already a pragma but due to incorrect restrictions it did not apply to clang.

This pull request has now been integrated.

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

8353458: Don't pass -Wno-format-nonliteral to CFLAGS

Reviewed-by: erikj

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

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

From magnus.ihse.bursie at oracle.com  Wed Apr  2 10:55:14 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 12:55:14 +0200
Subject: On passing --date to jrt-fs jar at build time
In-Reply-To: <CAAcPREv0bbF8cjfS-_T7tO3ztKcJQKZzZJBi6JcY=mN9bqeUJA@mail.gmail.com>
References: <CAAcPREun-zQXQweErGeUvJ7_O-aspMau0_gO=UbB1Rrt+z+mKw@mail.gmail.com>
 <36f0b94a1cea4623b40c2bd7e35d741e661fbd48.camel@redhat.com>
 <CAAcPREv0bbF8cjfS-_T7tO3ztKcJQKZzZJBi6JcY=mN9bqeUJA@mail.gmail.com>
Message-ID: <8f5ab6b5-63a6-42b0-ad8e-3de85a7d4293@oracle.com>

On 2025-03-28 11:28, Galder Zamarreno wrote:

>
>
> On Fri, Mar 28, 2025 at 11:00?AM Severin Gehwolf <sgehwolf at redhat.com> 
> wrote:
>
>     On Fri, 2025-03-28 at 10:25 +0100, Galder Zamarreno wrote:
>     > Hi,
>     >
>     > I continue experimenting with building mainline on Nix and I've made
>     > some progress. Capstone, Ant and others are in, but I had to work
>     > around an issue when trying to run JMH benchmarks [1].
>     >
>     > Seems like when `test` make target is run, `jrt-fs` jar file is
>     > created passing in `--date ...`. In Nix, I was getting this error:
>     >
>     > ```
>     >
>     /nix/store/5y040sypyg0amh0igxs9rnx5fmj0d88i-temurin-bin-23.0.2/bin/jar
>     --create --date 1980-01-01T00:00:00Z --file
>     /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/jrt-fs.jar
>     --manifest
>     /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/_the.jrt-fs.jar_manifest
>
>     > ...
>     > date 1980-01-01T00:00:00Z is not within the valid range
>     1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
>     > ```
>     >
>     > @Andrew Leonard?found the root of this validation in [2]. It seems
>     > unlikely this is going to change.
>     >
>     > The cause is that on Nix shell envs `$SOURCE_DATE_EPOCH` is set
>     > to?315532800 which is?1980-01-01T00:00:00Z. This can be easily
>     worked
>     > around by unsetting?SOURCE_DATE_EPOCH and that works fine for my use
>     > case.
>     >
>     > However,?@Thomas Fitzsimmons?had a very good point to make:
>     >
>     > > ?I also wonder why the test harness is passing --date
>     > > $SOURCE_DATE_EPOCH, since the test jars are not distributed, not
>     > > sure why they'd need to be reproducible...
>     >
>     > I think his question is valid. Why pass --date for a test jar?
>
>     I might be missing something, but isn't the question about why pass
>
>     --date $SOURCE_DATE_EPOCH
>
>     ... when creating jrt-fs.jar? jrt-fs.jar isn't a test jar. It's
>     the JDK
>     8 compatible FS provider for JDK 9+ to read the JRT files.
>
>     Are you suggesting it's only happening when running "make test"? I'd
>     assume the same would happen for 'make images' too after JDK-8288396.
>
>
> Before trying to run `make test` I was just simply calling `make` and 
> that didn't cause the jar to be created.

That will just call the default target, which is "jdk" unless you have 
set something different with configure. That is a convenience target for 
developers to get most, but not all, of the stuff built that is needed 
to check that you did not break the build and to be able to run a fair 
share of the tests.

You need to call "make jdk-image" to get a complete image that can be 
distributed.

I was going to point you to the relevant part of the build readme, but I 
noticed that this is not clearly spelled out there. I guess we should 
update the documentation to make this clear.


>
>     Couldn't you just set SOURCE_DATE_EPOCH to a value after 1980-01-
>     01T00:00:02Z (btw, that looks like a bug to me; valid range should
>     really be T00:00:00Z).
>
>
> Yes that would also work, same as unsetting SOURCE_DATE_EPOCH. About 
> the range, see the PR comment in [2]


You can use the "--with-source-date" configure option. With it, you can 
either pass in a ISO-8601 date string, or some of the convenience 
aliases. I'd recommend using "configure --with-source-date=version"; 
this will pick up the official release date of the JDK version you are 
building and using that to set SOURCE_DATE_EPOCH properly for all tools 
executed in the build.

/Magnus



>
>     Thanks,
>     Severin
>
>     > [1]
>     https://github.com/NixOS/nixpkgs/issues/387516#issuecomment-2760642591
>     > [2] https://github.com/openjdk/jdk/pull/6481#issuecomment-982399628
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250402/b21703e1/attachment-0001.htm>

From ihse at openjdk.org  Wed Apr  2 15:03:47 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 15:03:47 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <XKMHweGj95GRYWAwANKeDz_BUxdvtDyJJYiB-JiLViI=.d34c06ed-17d0-47e2-ae16-0c6dd670f58d@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

This seems reasonable to me. But there is so much old yucky stuff going on with the JDK bootstrapping issues, that I still get a bit nervous every time someone changes it.

Do you know *why* we do this, i.e. modify LD_LIBRARY_PATH?

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

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2772870911

From ihse at openjdk.org  Wed Apr  2 15:16:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 15:16:31 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
Message-ID: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@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.

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

Commit messages:
 - Revert "8352766: Problemlist hotspot tier1 tests requiring tools that are not included in static JDK"
 - Add build and main launcher support for relaunchers
 - Add native relaunchers
 - Simplify and prepare the main.c launcher

Changes: https://git.openjdk.org/jdk/pull/24380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346719
  Stats: 659 lines in 9 files changed: 518 ins; 111 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380

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

From ihse at openjdk.org  Wed Apr  2 15:16:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 15:16:31 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables
In-Reply-To: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
Message-ID: <zWAZ32suatuRsD4FM_VGnd1jAaxwfg-96RELZ1doKAY=.f4f1118b-6c88-49ac-aac1-65ae943a8b2e@github.com>

On Wed, 2 Apr 2025 14:54:35 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.

A bit of discussion/rationale for this PR:

* I did some preparation of the main launcher in 1d6c2ea66918667c2e9ef7619565cb3676a352d2. The old launcher code had a lot of weird stuff in `define.h` (which was not just defines, as the name implies). I simplified this and inlined it directly into main.c. I also renamed variables prefixed `const_`, because most of them will not be that after this PR, and it did not seem to bring much value to point this out in the name.
* Any changes in main.c apart from these are within `#ifdef STATIC_BUILD` only, and should not affect the normal launcher.
* The main launcher need some additional information to be able to launch any tool except the main "java" itself. Normally this is "hard-coded" into different builds of main.c by the use of compiler defines passed by the build. The approach I used for the static launcher is to pass this information as special system properties, with a name starting with `javaLauncher`. This will be treated as normal system properties by the launcher, but the additional code activated in the static build of the launcher will also interpret these values, and set the variables corresponding to how they would have been hardcoded in the dynamic launcher.
* This could have been achieved by using shell script/bat file relaunchers instead. However, that seemed more risky, since it would change the launchers from native binaries to text files. On Windows, for instance, other programs might look for "javac.exe" and not consider "javac.bat" to be acceptable.
* Finally, a commonly asked question when I developed this has been: "Could you not just symlink the java binary with different names, and then dispatch it depending on how it was called?". This is a common and clever technique, but it is not suitable here. First, it will not work on Windows. Secondly, it would require us to stuff all knowledge of all launchers into the main java binary. This solution, in contrast, distributes this knowledge out to every individual tool, making it possible to add new tools without modifying the main static binary.

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

PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2772911175

From ihse at openjdk.org  Wed Apr  2 18:03:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 18:03:24 GMT
Subject: RFR: 8349075: Once again allow -compilejdk in JAVAOPTIONS
Message-ID: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>

[JDK-8348905](https://bugs.openjdk.org/browse/JDK-8348905) added the possibility to set `JDK_FOR_COMPILE` on the command line to pass the `-compilejdk:` argument to jtreg. Unfortunately the way it did this meant that -compilejdk: were always passed, so trying to set it separately in JAVAOPTIONS failed due to a duplicate argument error.

This PR will instead only set  `-compilejdk:` if `JDK_FOR_COMPILE` is given on the command line.

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

Commit messages:
 - 8349075: Once again allow -compilejdk in JAVAOPTIONS

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

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

From rehn at openjdk.org  Wed Apr  2 18:34:52 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 2 Apr 2025 18:34:52 GMT
Subject: RFR: 8349075: Once again allow -compilejdk in JAVA_OPTIONS
In-Reply-To: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
References: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
Message-ID: <1DN777W5seZEe7JbhFGusRNy9lGsIBiAiS4fK5r4sDo=.c537866f-8249-467b-bd6d-7082d03ddd82@github.com>

On Wed, 2 Apr 2025 17:57:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348905](https://bugs.openjdk.org/browse/JDK-8348905) added the possibility to set `JDK_FOR_COMPILE` on the command line to pass the `-compilejdk:` argument to jtreg. Unfortunately the way it did this meant that -compilejdk: were always passed, so trying to set it separately in JAVAOPTIONS failed due to a duplicate argument error.
> 
> This PR will instead only set  `-compilejdk:` if `JDK_FOR_COMPILE` is given on the command line.

Thanks ! Looks good!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24386#pullrequestreview-2737212837

From magnus.ihse.bursie at oracle.com  Wed Apr  2 19:09:48 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 21:09:48 +0200
Subject: GHA on linux/aarch64
Message-ID: <369a6711-6a37-4bc9-b995-21ab16cc9714@oracle.com>

Apparently GitHub provides GHA Linux runners on aarch64 since a couple 
of months ago: 
https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

Should we replace our cross-compilation with native compilation? And/or 
add running tests on linux/aarch64 on GHA?

/Magnus


From vlivanov at openjdk.org  Wed Apr  2 19:42:57 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Apr 2025 19:42:57 GMT
Subject: RFR: 8353217: Build libsleef on macos-aarch64 [v3]
In-Reply-To: <F1iz2ONjUyctf1Vcq8MkM3B9qBJFrDm7LR8sm3PLuVc=.038e2c91-79e7-4bcf-8fdf-b21a9d4f5190@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
 <F1iz2ONjUyctf1Vcq8MkM3B9qBJFrDm7LR8sm3PLuVc=.038e2c91-79e7-4bcf-8fdf-b21a9d4f5190@github.com>
Message-ID: <Pt9724Hpn8TyOwqF534JO5iqDdYH8ZQ045B1YpG3c6E=.508a645f-baaf-48d8-ba7a-0746b6703693@github.com>

On Tue, 1 Apr 2025 22:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
>> 
>> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
>> 
>> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
>> 
>> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
>> 
>> Testing: hs-tier1 - hs-tier4, microbenchmarks
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust README.md

Thanks for the feedback and reviews, Julian, Vladimir, Aleksey, Magnus, and Erik.

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

PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2773549083

From vlivanov at openjdk.org  Wed Apr  2 19:45:59 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Apr 2025 19:45:59 GMT
Subject: Integrated: 8353217: Build libsleef on macos-aarch64
In-Reply-To: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
References: <YfQOQBydEPR0OTOqe9DmajY_nH0CiCgZk7oXucPnxNs=.d7153c9f-c0f9-4a5a-bfe1-5580416c1ab3@github.com>
Message-ID: <NtbMUbI8hR6U_VtFOVEJybanixoFj5h26N99xWTCvr0=.50efeb40-ccb7-4f7b-9ebc-7560fe993177@github.com>

On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Build and use SLEEF library as a backend implementation for Vector API trigonometric functions on macosx-aarch64 platform.
> 
> It improves raw throughput and eliminates GC overhead of non-intrinsified Vector API operation.
> 
> PR includes build changes and libsleef sources relocation from `src/jdk.incubator.vector/linux/native/` to `src/jdk.incubator.vector/share/native/`.
> 
> Once libsleef library is present, existing code in `stubGenerator_aarch64.cpp` successfully links at JVM startup. 
> 
> Testing: hs-tier1 - hs-tier4, microbenchmarks

This pull request has now been integrated.

Changeset: 130b0cda
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4
Stats:     167 lines in 176 files changed: 73 ins; 77 del; 17 mod

8353217: Build libsleef on macos-aarch64

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: erikj, kvn, ihse

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

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

From ihse at openjdk.org  Wed Apr  2 20:29:08 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 20:29:08 GMT
Subject: RFR: 8350774: Generated test-<testname> targets broken after
 JDK-8348998
Message-ID: <aYTB2dty_wHou96wyzioaw1uuVZtMv3nbtdDsiV2hAU=.6efedf1c-c0a8-4960-8407-e4f7bd6cb06f@github.com>

Unfortunately, JDK-8348998 broke the generation of the "test-<testname>" group of targets.

Or, rather, it breaks the first time you run it in a new configuration. The problem is that we need to populate the find-test.gmk cache before creating main-targets.gmk, and this was not done.

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

Commit messages:
 - 8350774: Generated test-<testname> targets broken after JDK-8348998

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

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

From ihse at openjdk.org  Wed Apr  2 20:44:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 20:44:26 GMT
Subject: RFR: 8349467: INIT_TARGETS tab completions on "make" lost with
 JDK-8348998
Message-ID: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>

[JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab completion for all init targets, i.e. `print-modules print-targets print-configuration print-tests reconfigure pre-compare-build post-compare-build`, of which `reconfigure` was probably the hardest hit.

The solution is to move the declaration of ALL_INIT_TARGETS so it is available even for the `SKIP_SPEC=true` part of PreInit.gmk.

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

Commit messages:
 - 8349467: INIT_TARGETS tab completions on "make" lost with JDK-8348998

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

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

From ihse at openjdk.org  Wed Apr  2 23:32:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 23:32:00 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
Message-ID: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>

Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

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

Commit messages:
 - 8353066: Properly detect Windows/aarch64 as build platform

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

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

From ihse at openjdk.org  Wed Apr  2 23:32:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2025 23:32:00 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <5BxcjHYpBGZmbY0WaoLK_JyJ66vyETGLW8kJt-jsZJI=.ac331dfd-162c-401e-89ec-463d0aed41fb@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

@swesonga @MBaesken Can you please verify that this works for you too?

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

PR Comment: https://git.openjdk.org/jdk/pull/24397#issuecomment-2773959071

From duke at openjdk.org  Thu Apr  3 03:45:47 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Thu, 3 Apr 2025 03:45:47 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <5BxcjHYpBGZmbY0WaoLK_JyJ66vyETGLW8kJt-jsZJI=.ac331dfd-162c-401e-89ec-463d0aed41fb@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
 <5BxcjHYpBGZmbY0WaoLK_JyJ66vyETGLW8kJt-jsZJI=.ac331dfd-162c-401e-89ec-463d0aed41fb@github.com>
Message-ID: <lb89zqpJDEdN4iMPjiWwsQKbt8IiaXQGpVlfuVfrgT4=.06591298-54ba-48f7-8f2d-c37c094adcb8@github.com>

On Wed, 2 Apr 2025 23:28:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @swesonga @MBaesken Can you please verify that this works for you too?

This works for me. The build type is native, the C++ compiler is an ARM64 binary, and the resulting build has ARM64 binaries. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/24397#issuecomment-2774402381

From jwaters at openjdk.org  Thu Apr  3 06:21:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 3 Apr 2025 06:21:01 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <fvXIIqhpItwYt8nRKqeyDW0yE-d8eioh50lipYJukaQ=.f33ef33c-c1b7-40be-bfdc-31667d0f12f1@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/873ad932...9d05cb8e

Argh, so it can't be replicated on Linux. Alright, I've troubled you enough by now, thank you so much for the help in testing Linux!

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2774604658

From dholmes at openjdk.org  Thu Apr  3 07:52:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Apr 2025 07:52:54 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <CpEOavgQIxuU5zTO1B12EHsjm5DFMsQwEI7HWQc-MSY=.6ce36a60-6a55-4940-b705-40ab7724f266@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

Yes this was related to JRE but was changed to JDK by JDK-8343040. It does appear to be trying to find the upper lib directory in:

JAVA_HOME/bin

given the JRE location. Hence it is meaningless (and potentially "dangerous"!) when given the JDK/JAVA_HOME location

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

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2774778621

From duke at openjdk.org  Thu Apr  3 08:05:17 2025
From: duke at openjdk.org (snake66)
Date: Thu, 3 Apr 2025 08:05:17 GMT
Subject: RFR: 8353580: libjpeg is not found if not installed in system
 directories
Message-ID: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>

The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.

This work is sponsored by The FreeBSD Foundation

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

Commit messages:
 - JDK-8353580: libjpeg is not found if not installed in system directories

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

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

From duke at openjdk.org  Thu Apr  3 08:09:41 2025
From: duke at openjdk.org (snake66)
Date: Thu, 3 Apr 2025 08:09:41 GMT
Subject: RFR: 8353573: System giflib not found by configure if it's not in
 system directories
Message-ID: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>

The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script. 

This work is sponsored by The FreeBSD Foundation

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

Commit messages:
 - 8353573: System giflib not found by configure if it's not in system directories

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

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

From ihse at openjdk.org  Thu Apr  3 09:01:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 09:01:57 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <D-pRBGcDZZ9RUkwQ6nBgh-INi_b_f7Lskf0CkQFeA74=.ea42511e-0e2f-4bba-9e66-653b472a042e@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739039686

From ihse at openjdk.org  Thu Apr  3 09:03:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 09:03:55 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <vP_zVr7f3x-7ctL1Q0muO2ogAZ92puL30ExjgSXzrAA=.a7b418f6-9d7e-4560-b2cf-96e8312c43bd@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

As a side note, I noticed that just installing the Visual Studio BuildTools was not enough to get the native aarch64 version of the toolchain. :-( For that you needed to install the whole Visual Studio, including the IDE. I have no idea why, but it is annoying. Unless Microsoft fixes that quickly, that it perhaps yet another thing we should document. (I believe the current documentation claims that the BuildTools installation is all that is needed.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24397#issuecomment-2774965651

From ihse at openjdk.org  Thu Apr  3 09:49:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 09:49:15 GMT
Subject: RFR: 8340341: Abort in configure when using Xcode 16.0 or 16.1
Message-ID: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>

The JDK mainline build when using XCode 16 or 16.1 fails with:


* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)


This is due to a compiler bug in Xcode, which was fixed in 16.2. We should catch this at configure time, since the build error is very confusing.

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

Commit messages:
 - 8340341: Warn in configure when using Xcode 16.0 or 16.1

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

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

From ihse at openjdk.org  Thu Apr  3 10:10:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 10:10:25 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
Message-ID: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>

When running configure on WSL, the following error message is printed, instead of proper Linux environment info:


    /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 


This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.

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

Commit messages:
 - 8315844: $LSB_RELEASE is not defined before use

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

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

From jpai at openjdk.org  Thu Apr  3 12:59:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Apr 2025 12:59:49 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

Hello @JoKern65, the change looks reasonable to me. Please give me a day or so to run this change against our CI. In the meantime, could you please update the copyright years on `java_md.c` and the `Test7029048.java` files?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739755041

From jkern at openjdk.org  Thu Apr  3 13:09:10 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 3 Apr 2025 13:09:10 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v2]
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <yFtCopsyRw24F7SBFxJ2k-a8gao7gYTKekPLwhel6EI=.562b2812-6edd-43e0-9c35-50e67f11b9ff@github.com>

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

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

  copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24351/files
  - new: https://git.openjdk.org/jdk/pull/24351/files/9d41d444..6f32ead9

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

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

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

From jpai at openjdk.org  Thu Apr  3 13:19:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Apr 2025 13:19:50 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v2]
In-Reply-To: <yFtCopsyRw24F7SBFxJ2k-a8gao7gYTKekPLwhel6EI=.562b2812-6edd-43e0-9c35-50e67f11b9ff@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 <yFtCopsyRw24F7SBFxJ2k-a8gao7gYTKekPLwhel6EI=.562b2812-6edd-43e0-9c35-50e67f11b9ff@github.com>
Message-ID: <1ZlVOX-syJsHCcWc4yTKeGaYofqbzGPSKOpTzq42xaU=.ff26b49e-397a-4012-aaad-b897adfaa8a2@github.com>

On Thu, 3 Apr 2025 13:09:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
>> 
>> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2739814339

From ihse at openjdk.org  Thu Apr  3 13:51:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 13:51:57 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually needed
Message-ID: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>

We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.

I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

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

Commit messages:
 - 8301197: Make sure use of printf is correct and actually needed

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

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

From jwaters at openjdk.org  Thu Apr  3 14:41:50 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 3 Apr 2025 14:41:50 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
Message-ID: <Jy8ai4XUKCxrhFmU_2mAwwczTcJRFAKTP30c-ES8g7I=.791fb6b7-756e-41ff-a96f-12fbfc8cbc8f@github.com>

On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When running configure on WSL, the following error message is printed, instead of proper Linux environment info:
> 
> 
>     /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 
> 
> 
> This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.

Looks good, just 1 question

make/autoconf/basic_tools.m4 line 109:

> 107:   UTIL_LOOKUP_PROGS(WHOAMI, whoami)
> 108: 
> 109:   # Tools only needed on some platforms

Comment still relevant? Or is it needed on all platforms?

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24409#pullrequestreview-2740142274
PR Review Comment: https://git.openjdk.org/jdk/pull/24409#discussion_r2027156433

From jwaters at openjdk.org  Thu Apr  3 14:42:58 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 3 Apr 2025 14:42:58 GMT
Subject: RFR: 8340341: Abort in configure when using Xcode 16.0 or 16.1
In-Reply-To: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
References: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
Message-ID: <x0-ASSOypPAVFc6UBEtbAvIA1NsayxMY_GmYf8fa5hU=.d10b7cce-7f4d-4bff-b7b1-c32721e829ef@github.com>

On Thu, 3 Apr 2025 09:44:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The JDK mainline build when using XCode 16 or 16.1 fails with:
> 
> 
> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
> 
> 
> This is due to a compiler bug in Xcode, which was fixed in 16.2. We should catch this at configure time, since the build error is very confusing.

Good call!

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24408#pullrequestreview-2740147375

From hannesw at openjdk.org  Thu Apr  3 15:03:35 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 3 Apr 2025 15:03:35 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc snippets
Message-ID: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>

Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

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

Commit messages:
 - Remove trailing spaces
 - Brigthen variable color
 - Fix regular expression for type arguments
 - 8348282: Add option for syntax highlighting in javadoc snippets

Changes: https://git.openjdk.org/jdk/pull/24417/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24417&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348282
  Stats: 3531 lines in 13 files changed: 3516 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24417/head:pull/24417

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

From aleonard at openjdk.org  Thu Apr  3 15:28:06 2025
From: aleonard at openjdk.org (Andrew Leonard)
Date: Thu, 3 Apr 2025 15:28:06 GMT
Subject: RFR: 8352481: Enforce the use of lld with clang [v7]
In-Reply-To: <Ia7NidTh6CmMyRBVaYZ0CzAWJHBYlOYMgwKg_62w9FU=.f4e3be3a-1087-45e5-83cf-66b911fdedd6@github.com>
References: <bpleaacG2mfGfHOWX298ZzCyjtnwHPbnf4FLdOzNnOU=.dc70dfc9-8dc9-42a2-be96-5b3870b87128@github.com>
 <wWAkI-JeLKpxtSP-zA9I7MXjWI4pHqxLSElZYPD3fMM=.288a3459-2cd9-4a64-a3b7-35aed8c2aec4@github.com>
 <Ia7NidTh6CmMyRBVaYZ0CzAWJHBYlOYMgwKg_62w9FU=.f4e3be3a-1087-45e5-83cf-66b911fdedd6@github.com>
Message-ID: <V4AUeoDjzk5PHg09oN6vL4Avle8ekZypgbZCbdDFSX8=.faff8e84-6fae-418b-adc2-23f26bf27ab1@github.com>

On Thu, 27 Mar 2025 02:21:30 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force use of lld when build os is not macosx
>
> make/autoconf/toolchain.m4 line 625:
> 
>> 623:     # Force use of lld, since that is what we expect when setting flags later on
>> 624:     if test "x$TOOLCHAIN_TYPE" = xclang; then
>> 625:       if test "x$OPENJDK_BUILD_OS" != "xmacosx"; then
> 
> According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker.

@sendaoYan fyi, i've raised a new bug as this fails to build on AIX clang: https://bugs.openjdk.org/browse/JDK-8353658

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24125#discussion_r2027255076

From syan at openjdk.org  Thu Apr  3 15:36:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 3 Apr 2025 15:36:20 GMT
Subject: RFR: 8352481: Enforce the use of lld with clang [v7]
In-Reply-To: <Ia7NidTh6CmMyRBVaYZ0CzAWJHBYlOYMgwKg_62w9FU=.f4e3be3a-1087-45e5-83cf-66b911fdedd6@github.com>
References: <bpleaacG2mfGfHOWX298ZzCyjtnwHPbnf4FLdOzNnOU=.dc70dfc9-8dc9-42a2-be96-5b3870b87128@github.com>
 <wWAkI-JeLKpxtSP-zA9I7MXjWI4pHqxLSElZYPD3fMM=.288a3459-2cd9-4a64-a3b7-35aed8c2aec4@github.com>
 <Ia7NidTh6CmMyRBVaYZ0CzAWJHBYlOYMgwKg_62w9FU=.f4e3be3a-1087-45e5-83cf-66b911fdedd6@github.com>
Message-ID: <MdbCDe1C9fY69SZWDLvnR_A51KWzpMBCW-oWB6DeL0Q=.7ff6ccaf-ca81-4f9b-b00b-7e10a5c3bc0c@github.com>

On Thu, 27 Mar 2025 02:21:30 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force use of lld when build os is not macosx
>
> make/autoconf/toolchain.m4 line 625:
> 
>> 623:     # Force use of lld, since that is what we expect when setting flags later on
>> 624:     if test "x$TOOLCHAIN_TYPE" = xclang; then
>> 625:       if test "x$OPENJDK_BUILD_OS" != "xmacosx"; then
> 
> According to the implementation of makefile function `FLAGS_SETUP_LDFLAGS_HELPER` which locate in make/autoconf/flags-ldflags.m4 file, only the combination of `$TOOLCHAIN_TYPE == clang` and `$OPENJDK_TARGET_OS == linux` support lld linker.

> @sendaoYan fyi, i've raised a new bug as this fails to build on AIX clang: https://bugs.openjdk.org/browse/JDK-8353658

Hi @andrew-m-leonard, The new bug you mentioned seems duplicated to [JDK-8353005](https://bugs.openjdk.org/browse/JDK-8353005). Could you check that, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24125#discussion_r2027273470

From jlahoda at openjdk.org  Thu Apr  3 17:59:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 17:59:52 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v2]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@github.com>

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Using control characters to get backspace control character.
 - If there's no native library available, fall back to the standard provider.
 - Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24242/files
  - new: https://git.openjdk.org/jdk/pull/24242/files/77c41e46..d5176d68

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

  Stats: 152 lines in 11 files changed: 114 ins; 13 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/24242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242

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

From jlahoda at openjdk.org  Thu Apr  3 18:12:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 18:12:54 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v3]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@github.com>

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8352693
 - Using control characters to get backspace control character.
 - If there's no native library available, fall back to the standard provider.
 - Reflecting review feedback.
 - Removing trailing whitespace
 - 8352693: Use a simpler console reader instead of JLine for System.console()

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

Changes: https://git.openjdk.org/jdk/pull/24242/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=02
  Stats: 2519 lines in 19 files changed: 1920 ins; 592 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242

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

From jlahoda at openjdk.org  Thu Apr  3 18:12:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 18:12:54 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v2]
In-Reply-To: <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@github.com>
Message-ID: <blxPSfLmCXSPu0MeLGdz0-VjsQ_ZMkB6CHKv_3WoM14=.eb5062bd-0a60-405b-abf4-8b261adb39e1@github.com>

On Thu, 3 Apr 2025 17:59:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Using control characters to get backspace control character.
>  - If there's no native library available, fall back to the standard provider.
>  - Reflecting review feedback.

I have updated the PR based on most of the review comments so far:
- removed the unnecessary qualified exports (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- reduced line lengths (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- cleaned comments in the C code (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- cleaned up the makefiles (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- if the native library (for UNIX) is not available, fall back to the simple/default provider (although support for AIX would be great, of course) (https://github.com/openjdk/jdk/pull/24242/commits/c6256eeeabfd73e7e67bf7f8c18c337e6bb92534)
- I realized the backspace value can (and should) be read from the terminal as a control character, so I did that (https://github.com/openjdk/jdk/pull/24242/commits/d5176d68e8cc73914a0efef45a60f0ff03885bcc)

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

PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2776568012

From ihse at openjdk.org  Thu Apr  3 18:42:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 18:42:54 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <Jy8ai4XUKCxrhFmU_2mAwwczTcJRFAKTP30c-ES8g7I=.791fb6b7-756e-41ff-a96f-12fbfc8cbc8f@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
 <Jy8ai4XUKCxrhFmU_2mAwwczTcJRFAKTP30c-ES8g7I=.791fb6b7-756e-41ff-a96f-12fbfc8cbc8f@github.com>
Message-ID: <szaqEQJWkOX1QlZsc-1uunNrmk21Bhi5AILFqO5yhCw=.e12533ce-7036-4bae-ab87-1b0d7b124a77@github.com>

On Thu, 3 Apr 2025 14:39:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> When running configure on WSL, the following error message is printed, instead of proper Linux environment info:
>> 
>> 
>>     /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 
>> 
>> 
>> This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.
>
> make/autoconf/basic_tools.m4 line 109:
> 
>> 107:   UTIL_LOOKUP_PROGS(WHOAMI, whoami)
>> 108: 
>> 109:   # Tools only needed on some platforms
> 
> Comment still relevant? Or is it needed on all platforms?

No, so I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24409#discussion_r2027552724

From mikael at openjdk.org  Thu Apr  3 20:11:58 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 3 Apr 2025 20:11:58 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <WgmtiOcpFqXQLibu1oLp9s3vSxdc0heckaD587_12jY=.746516a5-db0e-4e99-8d1e-78266a8a8fa9@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

Looks good. Since I contributed some of the code it would be great to get one more Review(er).

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

Marked as reviewed by mikael (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24397#pullrequestreview-2741019894

From mikael at openjdk.org  Thu Apr  3 20:51:50 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 3 Apr 2025 20:51:50 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
Message-ID: <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>

On Thu, 3 Apr 2025 13:36:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
> 
> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

make/Docs.gmk line 267:

> 265: 	$$(call LogInfo, Creating overview.html for $1)
> 266: 	$$(call MakeDir, $$(@D))
> 267: 	$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' > $$@

For my education, why isn't this just `$$(ECHO) '$$($1_OVERVIEW_TEXT)' > $$@` ?

make/Init.gmk line 163:

> 161: 	            $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) $(BUILD_LOG_PIPE) || \
> 162: 	        ( exitcode=$$? && \
> 163: 	        $(ECHO) "" $(BUILD_LOG_PIPE_SIMPLE) && \

Just for my understanding, is the empty string needed, or "just" a stylistic choice?

make/autoconf/help.m4 line 295:

> 293:   $ECHO "* HS debug level: $HOTSPOT_DEBUG_LEVEL"
> 294:   $ECHO "* JVM variants:   $JVM_VARIANTS"
> 295:   $ECHO "* JVM features:   "

I believe this will now add a newline where there was none earlier, so the actual features will show up on a new line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027670453
PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027674403
PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027700449

From ihse at openjdk.org  Thu Apr  3 21:10:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Apr 2025 21:10:51 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
Message-ID: <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>

On Thu, 3 Apr 2025 20:15:00 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
>> 
>> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.
>
> make/Docs.gmk line 267:
> 
>> 265: 	$$(call LogInfo, Creating overview.html for $1)
>> 266: 	$$(call MakeDir, $$(@D))
>> 267: 	$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' > $$@
> 
> For my education, why isn't this just `$$(ECHO) '$$($1_OVERVIEW_TEXT)' > $$@` ?

That would add an extra \n at the end. Maybe it does not matter so much, but I did not want to change anything.

> make/Init.gmk line 163:
> 
>> 161: 	            $(PARALLEL_TARGETS) $(COMPARE_BUILD_MAKE) $(BUILD_LOG_PIPE) || \
>> 162: 	        ( exitcode=$$? && \
>> 163: 	        $(ECHO) "" $(BUILD_LOG_PIPE_SIMPLE) && \
> 
> Just for my understanding, is the empty string needed, or "just" a stylistic choice?

Yeah, it is a stylistic choice to indicate that the line was intentionally left empty.

> make/autoconf/help.m4 line 295:
> 
>> 293:   $ECHO "* HS debug level: $HOTSPOT_DEBUG_LEVEL"
>> 294:   $ECHO "* JVM variants:   $JVM_VARIANTS"
>> 295:   $ECHO "* JVM features:   "
> 
> I believe this will now add a newline where there was none earlier, so the actual features will show up on a new line?

Good catch; I'll fix that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027743799
PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027744477
PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027745056

From prr at openjdk.org  Thu Apr  3 21:43:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Apr 2025 21:43:54 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <piSk974sE2niTfFjb6uS058KHkEAvykBNFCTRUSVG_8=.c12142ed-8902-442f-a00b-53ebaf14b12c@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

works for me on Windows 11 aarch64
generated the right configure and the build seems to be doing aarch64 things.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24397#pullrequestreview-2741234059

From jpai at openjdk.org  Fri Apr  4 01:33:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Apr 2025 01:33:48 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v2]
In-Reply-To: <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 <-jGUmaeX6LpbFkDH7euctBwxj4t-qEeMB0VPKPAdJmo=.b21af75f-f50b-4d20-9e3f-a2e29b83c07a@github.com>
Message-ID: <tjGAVR3AaNQnN8MJemauhxmWMo8RoY5FhojnOLBPIzw=.a8c52b7b-58a8-4d95-940a-7336f236259d@github.com>

On Thu, 3 Apr 2025 12:57:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Please give me a day or so to run this change against our CI.

tier1, tier2 and tier3 testing of this change went fine in our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2777338708

From dholmes at openjdk.org  Fri Apr  4 02:25:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Apr 2025 02:25:51 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
Message-ID: <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>

On Thu, 3 Apr 2025 21:07:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/Docs.gmk line 267:
>> 
>>> 265: 	$$(call LogInfo, Creating overview.html for $1)
>>> 266: 	$$(call MakeDir, $$(@D))
>>> 267: 	$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' > $$@
>> 
>> For my education, why isn't this just `$$(ECHO) '$$($1_OVERVIEW_TEXT)' > $$@` ?
>
> That would add an extra \n at the end. Maybe it does not matter so much, but I did not want to change anything.

`echo -n` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027989940

From dholmes at openjdk.org  Fri Apr  4 02:38:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Apr 2025 02:38:54 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
Message-ID: <x-ftyHvH0lY6MWRGaP19ju5WIUrNQO699ATE4zjK_2E=.adc8b911-6b8a-49a4-9ebe-f3670c8e65d2@github.com>

On Thu, 3 Apr 2025 13:36:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
> 
> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

Overall looks good to me.

make/common/modules/GensrcCommon.gmk line 45:

> 43: 	$$(call MakeTargetDir)
> 44: 	$(PRINTF) "jdk=%s\nfull=%s\nrelease=%s\n" \
> 45: 	    $(VERSION_NUMBER) $(VERSION_STRING) $(VERSION_SHORT) > $$@

Can't this just use echo like you did with the windows version elsewhere?

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

PR Review: https://git.openjdk.org/jdk/pull/24415#pullrequestreview-2741631300
PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027997961

From dholmes at openjdk.org  Fri Apr  4 02:38:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Apr 2025 02:38:55 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
Message-ID: <SdPN1BqRyIXap6ywjo43ctThxNShcuYr3AhHUnX1s0o=.c926bfc5-b1c5-45dd-bcdf-ac4ffc77e215@github.com>

On Thu, 3 Apr 2025 21:08:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/help.m4 line 295:
>> 
>>> 293:   $ECHO "* HS debug level: $HOTSPOT_DEBUG_LEVEL"
>>> 294:   $ECHO "* JVM variants:   $JVM_VARIANTS"
>>> 295:   $ECHO "* JVM features:   "
>> 
>> I believe this will now add a newline where there was none earlier, so the actual features will show up on a new line?
>
> Good catch; I'll fix that.

Again `echo -n`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2027995005

From erikj at openjdk.org  Fri Apr  4 06:31:47 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 06:31:47 GMT
Subject: RFR: 8349075: Once again allow -compilejdk in JAVA_OPTIONS
In-Reply-To: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
References: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
Message-ID: <7VbQ4lbeyoa6KhpIYN-Iw-EMW1mJ0Gjqqnq30kn_HtI=.ed2412e7-c652-4c06-8f78-e001a10c88c2@github.com>

On Wed, 2 Apr 2025 17:57:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348905](https://bugs.openjdk.org/browse/JDK-8348905) added the possibility to set `JDK_FOR_COMPILE` on the command line to pass the `-compilejdk:` argument to jtreg. Unfortunately the way it did this meant that -compilejdk: were always passed, so trying to set it separately in JAVAOPTIONS failed due to a duplicate argument error.
> 
> This PR will instead only set  `-compilejdk:` if `JDK_FOR_COMPILE` is given on the command line.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24386#pullrequestreview-2741897083

From erikj at openjdk.org  Fri Apr  4 06:47:49 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 06:47:49 GMT
Subject: RFR: 8350774: Generated test-<testname> targets broken after
 JDK-8348998
In-Reply-To: <aYTB2dty_wHou96wyzioaw1uuVZtMv3nbtdDsiV2hAU=.6efedf1c-c0a8-4960-8407-e4f7bd6cb06f@github.com>
References: <aYTB2dty_wHou96wyzioaw1uuVZtMv3nbtdDsiV2hAU=.6efedf1c-c0a8-4960-8407-e4f7bd6cb06f@github.com>
Message-ID: <jQ84Fvcoo3ORyQfyqfRoInmO2ZeFaESZCKYw_J1zSnE=.9fb7c66f-e5cc-481d-8735-fdfc1af7df68@github.com>

On Wed, 2 Apr 2025 20:24:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Unfortunately, JDK-8348998 broke the generation of the "test-<testname>" group of targets.
> 
> Or, rather, it breaks the first time you run it in a new configuration. The problem is that we need to populate the find-test.gmk cache before creating main-targets.gmk, and this was not done.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24391#pullrequestreview-2741929558

From erikj at openjdk.org  Fri Apr  4 06:49:49 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 06:49:49 GMT
Subject: RFR: 8349467: INIT_TARGETS tab completions on "make" lost with
 JDK-8348998
In-Reply-To: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
References: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
Message-ID: <xbCrrbwCFwa2np_0OYM1lpjTUtfrN1f9JuSeHYpJuoo=.3f4a596c-707f-43c7-bd6e-3c021b1f98eb@github.com>

On Wed, 2 Apr 2025 20:38:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab completion for all init targets, i.e. `print-modules print-targets print-configuration print-tests reconfigure pre-compare-build post-compare-build`, of which `reconfigure` was probably the hardest hit.
> 
> The solution is to move the declaration of ALL_INIT_TARGETS so it is available even for the `SKIP_SPEC=true` part of PreInit.gmk.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24392#pullrequestreview-2741931700

From erikj at openjdk.org  Fri Apr  4 06:56:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 06:56:53 GMT
Subject: RFR: 8353580: libjpeg is not found if not installed in system
 directories
In-Reply-To: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
References: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
Message-ID: <E1cLq148pUmjzp9CksJ241yYQ0lgu6fhAdIEvj41ENQ=.05c68dca-616c-4dc5-86c6-ee223a51e413@github.com>

On Thu, 3 Apr 2025 07:59:26 GMT, snake66 <duke at openjdk.org> wrote:

> The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.
> 
> This work is sponsored by The FreeBSD Foundation

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24403#pullrequestreview-2741949342

From erikj at openjdk.org  Fri Apr  4 07:02:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:02:48 GMT
Subject: RFR: 8353573: System giflib not found by configure if it's not in
 system directories
In-Reply-To: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
References: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
Message-ID: <MJWapaODP7PRkhBcqJ2Ul3FRJ7Lozjkn9cTVRG9XuY0=.7c815089-fa89-44de-b777-113dd5a0a0a7@github.com>

On Thu, 3 Apr 2025 08:04:50 GMT, snake66 <duke at openjdk.org> wrote:

> The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script. 
> 
> This work is sponsored by The FreeBSD Foundation

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24404#pullrequestreview-2741983207

From erikj at openjdk.org  Fri Apr  4 07:03:50 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:03:50 GMT
Subject: RFR: 8340341: Abort in configure when using Xcode 16.0 or 16.1
In-Reply-To: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
References: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
Message-ID: <J-AQNWLq4e1KgQ2A1Kzji1ZdE3L2S2NL4wiWMdh00Zw=.62919453-4dfc-42df-b6ec-56d0327d2c30@github.com>

On Thu, 3 Apr 2025 09:44:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The JDK mainline build when using XCode 16 or 16.1 fails with:
> 
> 
> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
> 
> 
> This is due to a compiler bug in Xcode, which was fixed in 16.2. We should catch this at configure time, since the build error is very confusing.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24408#pullrequestreview-2741990429

From erikj at openjdk.org  Fri Apr  4 07:05:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:05:48 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <1kQUIpj2OOMVzOyNh97h8jXzQO23bx_5WOwaGD7tqtI=.d7deb172-37c5-4be6-a9d8-d9cfd4b5d00f@github.com>

On Thu, 3 Apr 2025 14:48:58 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

Build change looks trivially good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24417#pullrequestreview-2741999660

From erikj at openjdk.org  Fri Apr  4 07:06:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:06:51 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
Message-ID: <QGmoaBxY74oYohu80HUAHWRgE0gxqOpjUUQKi57emFM=.c72e9341-c170-4c81-8cf5-09e4fc8419b7@github.com>

On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When running configure on WSL, the following error message is printed, instead of proper Linux environment info:
> 
> 
>     /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 
> 
> 
> This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24409#pullrequestreview-2742007104

From erikj at openjdk.org  Fri Apr  4 07:10:49 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:10:49 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <-KWoP9H08DDkGz8ZioFHyBK93sH1YiEymh6aA83v8PM=.8c5d3aa6-1b22-41b4-88d3-cb959a251e25@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24397#pullrequestreview-2742013621

From erikj at openjdk.org  Fri Apr  4 07:19:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 07:19:51 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
 <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>
Message-ID: <7kLo4yyktVe5Hscq3492U0Ypxohy2ysYpCIrrtM3p4g=.88967566-a3ed-4b8c-9035-15dc866594dc@github.com>

On Fri, 4 Apr 2025 02:23:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> That would add an extra \n at the end. Maybe it does not matter so much, but I did not want to change anything.
>
> `echo -n` ?

I wasn't aware of that feature in `echo`, but I agree that if we are using printf just to omit the line break, then `echo -n` seems like a better choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2028251285

From clanger at openjdk.org  Fri Apr  4 07:53:31 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 07:53:31 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
Message-ID: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>

Currently, when building with `--with-external-symbols-in-bundles=public`, the debug symbols bundle contains the stripped pdb files. It should better have the full pdb files since stripped pdbs are in the runtime image already.

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

Commit messages:
 - JDK-8353709

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

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

From duke at openjdk.org  Fri Apr  4 07:56:01 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 07:56:01 GMT
Subject: RFR: 8353580: libjpeg is not found if not installed in system
 directories
In-Reply-To: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
References: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
Message-ID: <_6Rauz9VxU6d3Q0bBUIDC-EkRQUxBx5PkhhNisCpJhw=.4deb0495-a9c4-43a9-abb5-8173c78f27bc@github.com>

On Thu, 3 Apr 2025 07:59:26 GMT, snake66 <duke at openjdk.org> wrote:

> The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.
> 
> This work is sponsored by The FreeBSD Foundation

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

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

PR Comment: https://git.openjdk.org/jdk/pull/24403#issuecomment-2777855330

From clanger at openjdk.org  Fri Apr  4 07:56:43 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 07:56:43 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v2]
In-Reply-To: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
References: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
Message-ID: <tmbmcaMMvTD-jWCCWcwBRNem2tEO633377RnYu8Kkmo=.207b0b9d-6c8e-438b-b7c1-477f19d0376b@github.com>

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24057/files
  - new: https://git.openjdk.org/jdk/pull/24057/files/9845a213..da632788

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

  Stats: 91537 lines in 2517 files changed: 34915 ins; 46252 del; 10370 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

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

From duke at openjdk.org  Fri Apr  4 07:57:53 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Apr 2025 07:57:53 GMT
Subject: RFR: 8353573: System giflib not found by configure if it's not in
 system directories
In-Reply-To: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
References: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
Message-ID: <znPTQOswOI7hfur686-gnCrxyib747EV32qD_IFvwGI=.45ac8728-30e0-42c3-8968-916956614a9f@github.com>

On Thu, 3 Apr 2025 08:04:50 GMT, snake66 <duke at openjdk.org> wrote:

> The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script. 
> 
> This work is sponsored by The FreeBSD Foundation

@snake66 
Your change (at version 45c1a1ba9a5141d93d2feb9ab734e593ec94808f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24404#issuecomment-2777857877

From erikj at openjdk.org  Fri Apr  4 08:30:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 08:30:54 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
In-Reply-To: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
Message-ID: <eUFAaER6WJ_1akXULR-gJpHyH1tdc3L0uRVUajuI4G0=.d3c8b5b7-9518-4374-95c9-5aea2a66272f@github.com>

On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, when building with `--with-external-symbols-in-bundles=public`, the debug symbols bundle contains the stripped pdb files. It should better have the full pdb files since stripped pdbs are in the runtime image already.

Is the symbols bundle currently containing just the stripped pdbs, or both the full and the stripped pdbs?

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

PR Comment: https://git.openjdk.org/jdk/pull/24440#issuecomment-2777929871

From harald+jdklists at volse.no  Fri Apr  4 08:31:55 2025
From: harald+jdklists at volse.no (Harald Eilertsen)
Date: Fri, 4 Apr 2025 10:31:55 +0200
Subject: RFR: 8353580: libjpeg is not found if not installed in system
 directories
In-Reply-To: <E1cLq148pUmjzp9CksJ241yYQ0lgu6fhAdIEvj41ENQ=.05c68dca-616c-4dc5-86c6-ee223a51e413@github.com>
References: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
 <E1cLq148pUmjzp9CksJ241yYQ0lgu6fhAdIEvj41ENQ=.05c68dca-616c-4dc5-86c6-ee223a51e413@github.com>
Message-ID: <rqtp7ncwtpos5pakiu4zg6chqal7yxkht5hxxe2mjpogcikafb@weq57rur5tky>

On Fri, Apr 04, 2025 at 06:56:53AM +0000, Erik Joelsson wrote:
> On Thu, 3 Apr 2025 07:59:26 GMT, snake66 <duke at openjdk.org> wrote:
>
> > The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.
> >
> > This work is sponsored by The FreeBSD Foundation
>
> Marked as reviewed by erikj (Reviewer).

Thanks a lot for the review!

H!

From harald+jdklists at volse.no  Fri Apr  4 08:32:33 2025
From: harald+jdklists at volse.no (Harald Eilertsen)
Date: Fri, 4 Apr 2025 10:32:33 +0200
Subject: RFR: 8353573: System giflib not found by configure if it's not
 in system directories
In-Reply-To: <MJWapaODP7PRkhBcqJ2Ul3FRJ7Lozjkn9cTVRG9XuY0=.7c815089-fa89-44de-b777-113dd5a0a0a7@github.com>
References: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
 <MJWapaODP7PRkhBcqJ2Ul3FRJ7Lozjkn9cTVRG9XuY0=.7c815089-fa89-44de-b777-113dd5a0a0a7@github.com>
Message-ID: <lzzlyisr2sh2rfclqpbmmcx6a2wztdjo4kgkl2ehfafbnylac3@r23ldwevpu4l>

On Fri, Apr 04, 2025 at 07:02:48AM +0000, Erik Joelsson wrote:
> On Thu, 3 Apr 2025 08:04:50 GMT, snake66 <duke at openjdk.org> wrote:
>
> > The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script.
> >
> > This work is sponsored by The FreeBSD Foundation
>
> Marked as reviewed by erikj (Reviewer).

Thanks a lot for the review!

H!

From djelinski at openjdk.org  Fri Apr  4 08:37:49 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 4 Apr 2025 08:37:49 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
Message-ID: <vRXKRNr_oEmLDIZqupBrW4BcAAWk3-qaenA7RBkeMBQ=.3a349fc7-dea3-4034-a7cc-6b35a871f24b@github.com>

On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When running configure on WSL, the following error message is printed, instead of proper Linux environment info:
> 
> 
>     /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 
> 
> 
> This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24409#pullrequestreview-2742233310

From clanger at openjdk.org  Fri Apr  4 08:57:48 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 08:57:48 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
In-Reply-To: <eUFAaER6WJ_1akXULR-gJpHyH1tdc3L0uRVUajuI4G0=.d3c8b5b7-9518-4374-95c9-5aea2a66272f@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
 <eUFAaER6WJ_1akXULR-gJpHyH1tdc3L0uRVUajuI4G0=.d3c8b5b7-9518-4374-95c9-5aea2a66272f@github.com>
Message-ID: <fZLXfxCjXdWn418hmwVn6zz3pwCCXlKjxxFTjUdjB6o=.24892e0a-806e-42d5-adef-b767de6ef449@github.com>

On Fri, 4 Apr 2025 08:28:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Is the symbols bundle currently containing just the stripped pdbs, or both the full and the stripped pdbs?

Currently the bundle only contains the stripped pdb files.

This is because during preparation of the bundle files we rename the stripped.pdb files over the full pdb files if they are present. See [line 130 of Bundles.gmk](https://github.com/openjdk/jdk/blob/a13e34da3f81039b572fd6030d6ee63dfffad612/make/Bundles.gmk#L130).

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

PR Comment: https://git.openjdk.org/jdk/pull/24440#issuecomment-2777992315

From duke at openjdk.org  Fri Apr  4 09:16:49 2025
From: duke at openjdk.org (christian)
Date: Fri, 4 Apr 2025 09:16:49 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <zKDU4y29f7Mm5TfWVXVy3MAlbL8MgV1CJB1OUQ50u9E=.29985a9e-f2d1-483f-9d1e-baeee8bf1a52@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

Marked as reviewed by skateball at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/24397#pullrequestreview-2742334241

From jkern at openjdk.org  Fri Apr  4 09:22:10 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 4 Apr 2025 09:22:10 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <zwVepKILsP_Yhe1xDxvmlJFCobQKsbm6R_4mF6uINJA=.98970676-52f5-4f90-a2da-202420ef423d@github.com>

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

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

  Proposal from RealCLanger to further cleanup test Test7029048

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24351/files
  - new: https://git.openjdk.org/jdk/pull/24351/files/6f32ead9..4dc7da09

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

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

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

From clanger at openjdk.org  Fri Apr  4 09:27:53 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 4 Apr 2025 09:27:53 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: <zwVepKILsP_Yhe1xDxvmlJFCobQKsbm6R_4mF6uINJA=.98970676-52f5-4f90-a2da-202420ef423d@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 <zwVepKILsP_Yhe1xDxvmlJFCobQKsbm6R_4mF6uINJA=.98970676-52f5-4f90-a2da-202420ef423d@github.com>
Message-ID: <bSvjavdvUfPnoXnytilzF0ef_RZPEGgnii34QkWdzcw=.cf8247c2-7c10-4045-8a19-c1cc7843614c@github.com>

On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
>> 
>> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Proposal from RealCLanger to further cleanup test Test7029048

Thanks for adding the additional test cleanups. Let's run it through our testing once more.

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

PR Comment: https://git.openjdk.org/jdk/pull/24351#issuecomment-2778062669

From erikj at openjdk.org  Fri Apr  4 09:29:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 09:29:02 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
In-Reply-To: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
Message-ID: <-vFWQ1lUpWGGTQn4_5ixf3T_ocnjYxbcoo3RLMhQeIU=.8edbce99-8ece-4050-81d1-6b4e4cba500c@github.com>

On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, when building with `--with-external-symbols-in-bundles=public`, the debug symbols bundle contains the stripped pdb files. It should better have the full pdb files since stripped pdbs are in the runtime image already.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24440#pullrequestreview-2742362312

From erikj at openjdk.org  Fri Apr  4 09:29:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 09:29:02 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
In-Reply-To: <fZLXfxCjXdWn418hmwVn6zz3pwCCXlKjxxFTjUdjB6o=.24892e0a-806e-42d5-adef-b767de6ef449@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
 <eUFAaER6WJ_1akXULR-gJpHyH1tdc3L0uRVUajuI4G0=.d3c8b5b7-9518-4374-95c9-5aea2a66272f@github.com>
 <fZLXfxCjXdWn418hmwVn6zz3pwCCXlKjxxFTjUdjB6o=.24892e0a-806e-42d5-adef-b767de6ef449@github.com>
Message-ID: <LEsl-A2l9YA0e5gaC6CPKnzxF1PA3eInv5AGcTdReb8=.3198d066-672f-4408-82c2-2c59016b0c8e@github.com>

On Fri, 4 Apr 2025 08:55:40 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > Is the symbols bundle currently containing just the stripped pdbs, or both the full and the stripped pdbs?
> 
> Currently the bundle only contains the stripped pdb files.
> 
> This is because during preparation of the bundle files we rename the stripped.pdb files over the full pdb files if they are present. See [line 130 of Bundles.gmk](https://github.com/openjdk/jdk/blob/a13e34da3f81039b572fd6030d6ee63dfffad612/make/Bundles.gmk#L130).

Thanks for the explanation. Then the patch makes sense to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/24440#issuecomment-2778065071

From mdoerr at openjdk.org  Fri Apr  4 10:39:03 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Apr 2025 10:39:03 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <bbGnqC-QPy7_Rah3ZKxYRH8-WA8dMVw6MwivbkSzaBE=.7ec9714a-876d-429a-836d-97cdf9058d44@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

It'd be nice if we could have a default style for .java files in the future, too. This looks good to me for the time being.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23693#pullrequestreview-2742553046

From duke at openjdk.org  Fri Apr  4 12:45:54 2025
From: duke at openjdk.org (christian)
Date: Fri, 4 Apr 2025 12:45:54 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <piSk974sE2niTfFjb6uS058KHkEAvykBNFCTRUSVG_8=.c12142ed-8902-442f-a00b-53ebaf14b12c@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
 <piSk974sE2niTfFjb6uS058KHkEAvykBNFCTRUSVG_8=.c12142ed-8902-442f-a00b-53ebaf14b12c@github.com>
Message-ID: <zo4Rz7NaeD4CKISPUbBUacdPOKpQnwi0bCFEnyMEb0k=.31a3d3fe-5563-4220-87f3-8e60d7e7ffa1@github.com>

On Thu, 3 Apr 2025 21:41:21 GMT, Phil Race <prr at openjdk.org> wrote:

> works for me on Windows 11 aarch64 generated the right configure and the build seems to be doing aarch64 things.

same here. 
backported it locally to 21u and it works there, too. 
thx

Have you made it work with WSL2? made the configure work, but the build ran into issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/24397#issuecomment-2778035226

From ihse at openjdk.org  Fri Apr  4 13:22:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:22:15 GMT
Subject: RFR: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <szaqEQJWkOX1QlZsc-1uunNrmk21Bhi5AILFqO5yhCw=.e12533ce-7036-4bae-ab87-1b0d7b124a77@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
 <Jy8ai4XUKCxrhFmU_2mAwwczTcJRFAKTP30c-ES8g7I=.791fb6b7-756e-41ff-a96f-12fbfc8cbc8f@github.com>
 <szaqEQJWkOX1QlZsc-1uunNrmk21Bhi5AILFqO5yhCw=.e12533ce-7036-4bae-ab87-1b0d7b124a77@github.com>
Message-ID: <o7KtrKwqcxiMSS1lHrmVqbKZYw4AZq__goP4XXzNz5Q=.c7a0398c-7bc0-4bae-afb6-5d2c447c63a8@github.com>

On Thu, 3 Apr 2025 18:40:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/basic_tools.m4 line 109:
>> 
>>> 107:   UTIL_LOOKUP_PROGS(WHOAMI, whoami)
>>> 108: 
>>> 109:   # Tools only needed on some platforms
>> 
>> Comment still relevant? Or is it needed on all platforms?
>
> No, so I removed it.

Ah, sorry, now I realize what you meant (perhaps). I moved the line to a block of lookups that is already preceded by the very same comment. It is still true that lsb_release is only needed on some platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24409#discussion_r2028800957

From ihse at openjdk.org  Fri Apr  4 13:22:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:22:16 GMT
Subject: Integrated: 8315844: $LSB_RELEASE is not defined before use
In-Reply-To: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
References: <imub-UIsRPJAIeFuqhdxRwjV-kQ2OreKskV8NCxHXPc=.d543db5f-71ad-445d-9925-b2fc88a6a9ea@github.com>
Message-ID: <B-qPSA2D4aBrbpXfqUfubUB5qxxwuBWTpixWfdfSfgU=.0c1008af-b71e-4313-ba69-798954df68de@github.com>

On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When running configure on WSL, the following error message is printed, instead of proper Linux environment info:
> 
> 
>     /build/.configure-support/generated-configure.sh: line 13102: -d: command not found 
> 
> 
> This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined at that point in time. Fix this by moving the LSB_RELEASE check forward.

This pull request has now been integrated.

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

8315844: $LSB_RELEASE is not defined before use

Reviewed-by: jwaters, erikj, djelinski

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

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

From ihse at openjdk.org  Fri Apr  4 13:35:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:35:56 GMT
Subject: RFR: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <zo4Rz7NaeD4CKISPUbBUacdPOKpQnwi0bCFEnyMEb0k=.31a3d3fe-5563-4220-87f3-8e60d7e7ffa1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
 <piSk974sE2niTfFjb6uS058KHkEAvykBNFCTRUSVG_8=.c12142ed-8902-442f-a00b-53ebaf14b12c@github.com>
 <zo4Rz7NaeD4CKISPUbBUacdPOKpQnwi0bCFEnyMEb0k=.31a3d3fe-5563-4220-87f3-8e60d7e7ffa1@github.com>
Message-ID: <9XtbRA3MFOcIOtpmoEHT_GNzIzoC2pCsmSiwI5N3DcM=.45850684-8548-4e57-a885-c327ec82300c@github.com>

On Fri, 4 Apr 2025 09:14:12 GMT, christian <duke at openjdk.org> wrote:

> Have you made it work with WSL2? made the configure work, but the build ran into issues.

WSL2 has been more problematic to get to work with the OpenJDK build than WSL1. Don't be fooled by the "version" numbers, WSL1 is a completely different product from WSL2, and in many respects it's superior. I recommend using WSL1 to build OpenJDK.

With that said, I do not know of any particular issue prohibiting building on WSL2 (more than the abysmal performance). Please send a mail to build-dev at openjdk.org with details with your problem, if you need assistance.

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

PR Comment: https://git.openjdk.org/jdk/pull/24397#issuecomment-2778747677

From ihse at openjdk.org  Fri Apr  4 13:35:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:35:57 GMT
Subject: Integrated: 8353066: Properly detect Windows/aarch64 as build platform
In-Reply-To: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
References: <Xa0AsqxNM5k6MO1iecPcY3uNYEGcKss27VsLc4C4ILI=.063c3127-8687-4bc4-94bd-997db05186c1@github.com>
Message-ID: <d9pQ62DDSkTMBlK04s8swWg_zPGGjuH3jawEB_urn9U=.891571ae-b610-4f61-b303-cbe334fb0deb@github.com>

On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Configure does not properly detect Windows/aarch64 on Cygwin. One complicating factor here is that no native aarch64 version of Cygwin exists, so it is running x64 binaries in emulated mode.

This pull request has now been integrated.

Changeset: 3241b4e1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3241b4e111e3dbf475c0e5be117c2a8d1a63ad35
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8353066: Properly detect Windows/aarch64 as build platform

Co-authored-by: Mikael Vidstedt <mikael at openjdk.org>
Reviewed-by: mikael, prr, erikj

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

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

From ihse at openjdk.org  Fri Apr  4 13:38:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:38:04 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <x-ftyHvH0lY6MWRGaP19ju5WIUrNQO699ATE4zjK_2E=.adc8b911-6b8a-49a4-9ebe-f3670c8e65d2@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <x-ftyHvH0lY6MWRGaP19ju5WIUrNQO699ATE4zjK_2E=.adc8b911-6b8a-49a4-9ebe-f3670c8e65d2@github.com>
Message-ID: <eLp2ZCtEh2Nf-y4xLoOm3Cp1sjmFYAxK4xTu6VhY8c0=.210d8799-14f6-425b-ba18-0132fbf57484@github.com>

On Fri, 4 Apr 2025 02:35:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
>> 
>> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.
>
> make/common/modules/GensrcCommon.gmk line 45:
> 
>> 43: 	$$(call MakeTargetDir)
>> 44: 	$(PRINTF) "jdk=%s\nfull=%s\nrelease=%s\n" \
>> 45: 	    $(VERSION_NUMBER) $(VERSION_STRING) $(VERSION_SHORT) > $$@
> 
> Can't this just use echo like you did with the windows version elsewhere?

No, there are embedded `\n` and that does not work with echo. I could split it into three consecutive lines but I don't think that would be a gain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2028829226

From ihse at openjdk.org  Fri Apr  4 13:44:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:44:02 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <7kLo4yyktVe5Hscq3492U0Ypxohy2ysYpCIrrtM3p4g=.88967566-a3ed-4b8c-9035-15dc866594dc@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
 <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>
 <7kLo4yyktVe5Hscq3492U0Ypxohy2ysYpCIrrtM3p4g=.88967566-a3ed-4b8c-9035-15dc866594dc@github.com>
Message-ID: <dGi0HIF1RpUxqw4HSB86g3ZF9GBMt2ADPXwSJu506nQ=.8e46724d-a1b1-4d2b-91d0-2f76a1495430@github.com>

On Fri, 4 Apr 2025 07:17:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> `echo -n` ?
>
> I wasn't aware of that feature in `echo`, but I agree that if we are using printf just to omit the line break, then `echo -n` seems like a better choice.

I'm not sure I agree. Why would:

$$(ECHO) -n '$$($1_OVERVIEW_TEXT)' 

be better than

$$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' 

?

We're kind of squabbling over details here, and it really doesn't matter as much, but I don't think there is really anything to gain by going down that route. If nothing else, `echo -n` seems like less widespread knowledge (Erik didn't know, I knew but had forgot since I never use it). In contrast, I believe the printf syntax is a bit more well known.

But sure, I can use `echo -n` instead of `printf` where possible. Just give me one good reason why.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2028838781

From ihse at openjdk.org  Fri Apr  4 13:47:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:47:06 GMT
Subject: Integrated: 8340341: Abort in configure when using Xcode 16.0 or 16.1
In-Reply-To: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
References: <N_8RxKg0mphHN6cqRZcnHdImRmCXBX8_hiQzaL1E0xw=.981a5b17-7260-4441-b71c-a79d8d570cf7@github.com>
Message-ID: <39oIFMnnO0szrO-ovr4LNFlRZ-Q47a-zRScB9Cjr36o=.f40c9d72-88af-4522-bab9-d4da44414577@github.com>

On Thu, 3 Apr 2025 09:44:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The JDK mainline build when using XCode 16 or 16.1 fails with:
> 
> 
> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
> 
> 
> This is due to a compiler bug in Xcode, which was fixed in 16.2. We should catch this at configure time, since the build error is very confusing.

This pull request has now been integrated.

Changeset: 5520ff12
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5520ff12ec26dc2b490fb702101c3679a2af9a2d
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8340341: Abort in configure when using Xcode 16.0 or 16.1

Reviewed-by: jwaters, erikj

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

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

From ihse at openjdk.org  Fri Apr  4 13:47:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:47:14 GMT
Subject: Integrated: 8349467: INIT_TARGETS tab completions on "make" lost with
 JDK-8348998
In-Reply-To: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
References: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
Message-ID: <P_RlX1YZtF_4-uoWsmJi_UgZF9rwMlUst6kU1fKDeSc=.8a8ffde0-098c-4640-9c32-934390c7f51e@github.com>

On Wed, 2 Apr 2025 20:38:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab completion for all init targets, i.e. `print-modules print-targets print-configuration print-tests reconfigure pre-compare-build post-compare-build`, of which `reconfigure` was probably the hardest hit.
> 
> The solution is to move the declaration of ALL_INIT_TARGETS so it is available even for the `SKIP_SPEC=true` part of PreInit.gmk.

This pull request has now been integrated.

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

8349467: INIT_TARGETS tab completions on "make" lost with JDK-8348998

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Fri Apr  4 13:48:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:48:06 GMT
Subject: Integrated: 8350774: Generated test-<testname> targets broken after
 JDK-8348998
In-Reply-To: <aYTB2dty_wHou96wyzioaw1uuVZtMv3nbtdDsiV2hAU=.6efedf1c-c0a8-4960-8407-e4f7bd6cb06f@github.com>
References: <aYTB2dty_wHou96wyzioaw1uuVZtMv3nbtdDsiV2hAU=.6efedf1c-c0a8-4960-8407-e4f7bd6cb06f@github.com>
Message-ID: <3pbNkq5H88-eobYQEA0SdAhNLPiCd0pa-Onnc6vxx70=.90dcc4c6-baf6-4478-8803-d01993ae2c17@github.com>

On Wed, 2 Apr 2025 20:24:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Unfortunately, JDK-8348998 broke the generation of the "test-<testname>" group of targets.
> 
> Or, rather, it breaks the first time you run it in a new configuration. The problem is that we need to populate the find-test.gmk cache before creating main-targets.gmk, and this was not done.

This pull request has now been integrated.

Changeset: 9fb36099
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fb3609955b01c7026665d7baf06de9761391ce4
Stats:     7 lines in 4 files changed: 3 ins; 2 del; 2 mod

8350774: Generated test-<testname> targets broken after JDK-8348998

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Fri Apr  4 13:48:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 13:48:06 GMT
Subject: Integrated: 8349075: Once again allow -compilejdk in JAVA_OPTIONS
In-Reply-To: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
References: <6pTSH9P_Hgo81GqNfNlOeda1Ph5IAGJxg-15ibb_uxw=.86824f3e-c3b3-45fa-b657-aa4ad556b71e@github.com>
Message-ID: <vtJIbF0ZZDmj9NURjweu6zjtoeivAcW5sumDcuIlJqw=.b298d752-a840-4f30-87a3-9e7a10c19fda@github.com>

On Wed, 2 Apr 2025 17:57:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348905](https://bugs.openjdk.org/browse/JDK-8348905) added the possibility to set `JDK_FOR_COMPILE` on the command line to pass the `-compilejdk:` argument to jtreg. Unfortunately the way it did this meant that -compilejdk: were always passed, so trying to set it separately in JAVAOPTIONS failed due to a duplicate argument error.
> 
> This PR will instead only set  `-compilejdk:` if `JDK_FOR_COMPILE` is given on the command line.

This pull request has now been integrated.

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

8349075: Once again allow -compilejdk in JAVA_OPTIONS

Reviewed-by: rehn, erikj

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

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

From erikj at openjdk.org  Fri Apr  4 13:57:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 4 Apr 2025 13:57:12 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <dGi0HIF1RpUxqw4HSB86g3ZF9GBMt2ADPXwSJu506nQ=.8e46724d-a1b1-4d2b-91d0-2f76a1495430@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
 <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>
 <7kLo4yyktVe5Hscq3492U0Ypxohy2ysYpCIrrtM3p4g=.88967566-a3ed-4b8c-9035-15dc866594dc@github.com>
 <dGi0HIF1RpUxqw4HSB86g3ZF9GBMt2ADPXwSJu506nQ=.8e46724d-a1b1-4d2b-91d0-2f76a1495430@github.com>
Message-ID: <TC2h6u1FoP5mhvM3sjaHERuL-O03H1P3Od9TNM9_mw0=.303fdecf-e688-45bf-8da1-2a6add9d0a8d@github.com>

On Fri, 4 Apr 2025 13:41:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I wasn't aware of that feature in `echo`, but I agree that if we are using printf just to omit the line break, then `echo -n` seems like a better choice.
>
> I'm not sure I agree. Why would:
> 
> $$(ECHO) -n '$$($1_OVERVIEW_TEXT)' 
> 
> be better than
> 
> $$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' 
> 
> ?
> 
> We're kind of squabbling over details here, and it really doesn't matter as much, but I don't think there is really anything to gain by going down that route. If nothing else, `echo -n` seems like less widespread knowledge (Erik didn't know, I knew but had forgot since I never use it). In contrast, I believe the printf syntax is a bit more well known.
> 
> But sure, I can use `echo -n` instead of `printf` where possible. Just give me one good reason why.

I just thought that if you tried to standardized on `echo` where possible instead of `printf`, it would make sense. I often feel awkward having to switch to the completely different syntax of printf just to prevent the newline. Having a simple option to echo that just omits the newline seems more straightforward. There are of course still usecases for printf. I don't mind that much either way though, so I'm really fine with either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2028859754

From ihse at openjdk.org  Fri Apr  4 14:03:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:03:15 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
Message-ID: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>

Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing JDK-8311227.

This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck into .editorconfig format. I believe that is a better way to introduce an `.editorconfig` file into the existing JDK project.

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

Commit messages:
 - 8311227: Add .editorconfig

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

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

From ihse at openjdk.org  Fri Apr  4 14:06:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:06:10 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <g0omo8wmfUsofZkZS-2ydwL03eyVuF9BIW0jJQZmbXM=.379b3757-c431-49ed-a228-2d609e8a00f5@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

I still don't think the .editorconfig as suggested here is a good idea. It directly conflicts with the existing logic in jcheck.

Understand me right -- I am all in favor of tightening the structure of our code base. But we can't do that by introducing an .editorconfig that does not match what is currently enforced by jcheck or is the current standard of the code base. Instead, we need to tighten the rules bit by bit, getting buy-in for tighter rules, and ensuring we update and fix all old files. 

I have published an alternative implementation of this issue at https://github.com/openjdk/jdk/pull/24448. That version of .editorconfig has a 1-to-1 correspondence to what is checked by jcheck.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2778823752

From ihse at openjdk.org  Fri Apr  4 14:07:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:07:53 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <TC2h6u1FoP5mhvM3sjaHERuL-O03H1P3Od9TNM9_mw0=.303fdecf-e688-45bf-8da1-2a6add9d0a8d@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <PFh0iPHRaTPIkw3zBuuJMuVJAcWmtSrBS4l4zmCtzIM=.9e44d504-fddc-4481-8a65-6da00067a25a@github.com>
 <3Mo3Plrj2E504kdWwpJ9jOcAW6UX2_oRwdvUEE5BDGE=.1a8ed7fc-6323-40e2-bf93-19315d9e0674@github.com>
 <vOUQLWyA86kGhQat9zkg12lWtzWeu8oa4C81vPwdFF4=.e1d4e7fd-6cd3-4893-bc16-5649db7514a5@github.com>
 <7kLo4yyktVe5Hscq3492U0Ypxohy2ysYpCIrrtM3p4g=.88967566-a3ed-4b8c-9035-15dc866594dc@github.com>
 <dGi0HIF1RpUxqw4HSB86g3ZF9GBMt2ADPXwSJu506nQ=.8e46724d-a1b1-4d2b-91d0-2f76a1495430@github.com>
 <TC2h6u1FoP5mhvM3sjaHERuL-O03H1P3Od9TNM9_mw0=.303fdecf-e688-45bf-8da1-2a6add9d0a8d@github.com>
Message-ID: <-BOBn55FA_3a3onms4IkUvKBdNYOwANU9s48iNrzaOc=.a15a5739-3944-4c9b-8a61-81e128a71438@github.com>

On Fri, 4 Apr 2025 13:53:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I'm not sure I agree. Why would:
>> 
>> $$(ECHO) -n '$$($1_OVERVIEW_TEXT)' 
>> 
>> be better than
>> 
>> $$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)' 
>> 
>> ?
>> 
>> We're kind of squabbling over details here, and it really doesn't matter as much, but I don't think there is really anything to gain by going down that route. If nothing else, `echo -n` seems like less widespread knowledge (Erik didn't know, I knew but had forgot since I never use it). In contrast, I believe the printf syntax is a bit more well known.
>> 
>> But sure, I can use `echo -n` instead of `printf` where possible. Just give me one good reason why.
>
> I just thought that if you tried to standardized on `echo` where possible instead of `printf`, it would make sense. I often feel awkward having to switch to the completely different syntax of printf just to prevent the newline. Having a simple option to echo that just omits the newline seems more straightforward. There are of course still usecases for printf. I don't mind that much either way though, so I'm really fine with either.

Okay, fine. That's a good enough reason. I'll switch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2028878464

From ihse at openjdk.org  Fri Apr  4 14:22:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:22:17 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed [v2]
In-Reply-To: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
Message-ID: <4U9sFWHV6JHI5O4arzrHm5tyZw9EXTbuEOx76Bf2i6o=.93a1956a-0073-41da-b609-1e7056bfe7cc@github.com>

> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
> 
> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

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

 - One more
 - Ooops...
 - Use echo -n where possible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24415/files
  - new: https://git.openjdk.org/jdk/pull/24415/files/08a7dc92..db4cdc8a

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

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

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

From mbaesken at openjdk.org  Fri Apr  4 14:25:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Apr 2025 14:25:50 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v3]
In-Reply-To: <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
Message-ID: <kd5M0SLAsW-qQ8Qqqx3bBbVfyVfXTibZt7VT0fgVW6Y=.f2e04ff8-9dd9-4f00-9c2a-2b5e5e0b231e@github.com>

On Mon, 31 Mar 2025 18:11:27 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add instructions for a native Windows AArch64 build

With
8353066: Properly detect Windows/aarch64 as build platform
pushed, we do not need any more the special configure flag.
But as far as I remember there was something about details what part of VS is needed (so the aarch tools / compiler(s) are present) , is that correct  ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2778880227

From ihse at openjdk.org  Fri Apr  4 14:27:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:27:53 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v3]
In-Reply-To: <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@github.com>
Message-ID: <dhZl33lSZkIzVyFtczo2qy4s4Ti_uVAsJfBL_NDFw3U=.502a77fd-797c-42de-b549-3a8b9592ed14@github.com>

On Thu, 3 Apr 2025 18:12:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8352693
>  - Using control characters to get backspace control character.
>  - If there's no native library available, fall back to the standard provider.
>  - Reflecting review feedback.
>  - Removing trailing whitespace
>  - 8352693: Use a simpler console reader instead of JLine for System.console()

make/modules/jdk.internal.le/Lib.gmk line 31:

> 29: 
> 30: ifeq ($(call isTargetOs, linux macosx windows), true)
> 31: 

Can you please insert the standardized header we use for native libraries? (These are extremely helpful to find/locate where certain libraries are built, since there is no existing proper IDE support for makefiles.)

Suggestion:

  ##############################################################################
  ## Build lible
  ##############################################################################

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2028914120

From ihse at openjdk.org  Fri Apr  4 14:30:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:30:51 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v3]
In-Reply-To: <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
Message-ID: <COFhKWNb4zLCc9CTxLYFnIwQTEsPwrkl7oMvk5Xz2jk=.9c7f1b3f-bd7a-4e57-b620-2498f34035da@github.com>

On Mon, 31 Mar 2025 18:11:27 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add instructions for a native Windows AArch64 build

It might still make sense to document that to cross-compile to aarch64, the flag `--openjdk-target=aarch64-unknown-cygwin` should be used -- that is in no way obvious or trivial to figure out.

I think what you are talking about is the fact that, at least currently, the BuildTools distribution of Visual Studio do not include aarch64-hosted compilers, so to be able to run native builds without the Prism emulation, you need to install the full Visual Studio, including the IDE. This too might be worth documenting, with the caveat that it applies currently but might change in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2778893458

From ihse at openjdk.org  Fri Apr  4 14:32:30 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:32:30 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed [v3]
In-Reply-To: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
Message-ID: <QKJ98yRxGJ6HYAX-dmqYSl39S22JXk_48CVKJDH8Gms=.829a0afe-c751-4e3b-8c37-268209a006e0@github.com>

> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
> 
> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

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

  echo do not need escaped quotes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24415/files
  - new: https://git.openjdk.org/jdk/pull/24415/files/db4cdc8a..a1b16a75

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

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

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

From ihse at openjdk.org  Fri Apr  4 14:35:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:35:37 GMT
Subject: RFR: 8349665: Make clean removes module-deps.gmk
Message-ID: <gGBWkIwQaOHN9hHyV1oaKxD0_BBmzb4sTLf_Yvj2YPc=.0243fdef-08c4-4fce-aea7-7cfba76b649e@github.com>

After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean <some other target>` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies.

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

Commit messages:
 - 8349665: Make clean removes module-deps.gmk

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

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

From ihse at openjdk.org  Fri Apr  4 14:35:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:35:37 GMT
Subject: RFR: 8349665: Make clean removes module-deps.gmk
In-Reply-To: <gGBWkIwQaOHN9hHyV1oaKxD0_BBmzb4sTLf_Yvj2YPc=.0243fdef-08c4-4fce-aea7-7cfba76b649e@github.com>
References: <gGBWkIwQaOHN9hHyV1oaKxD0_BBmzb4sTLf_Yvj2YPc=.0243fdef-08c4-4fce-aea7-7cfba76b649e@github.com>
Message-ID: <mWqf9jwnVzfT_SHh4KQ6v4tqGgQID8MMypuRYs_TUoo=.5417ffa3-a472-4573-97fb-7528a46baf97@github.com>

On Thu, 3 Apr 2025 09:18:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean <some other target>` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies.

Due to known upcoming merge conflicts, I will not try to integrate this until after JDK-8350774. They are not strictly dependent on each other, but JDK-8350774 will cause a merge conflict for this patch, and vice versa.

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

PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2775378854

From sgehwolf at openjdk.org  Fri Apr  4 15:27:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 15:27:51 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: <BRlwsTVZQloBa-RoKMyiCNCzRtqHLHdgtQgO3t6qX_8=.38449b2d-3605-415e-9b49-bd2ba9520bea@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
 <BRlwsTVZQloBa-RoKMyiCNCzRtqHLHdgtQgO3t6qX_8=.38449b2d-3605-415e-9b49-bd2ba9520bea@github.com>
Message-ID: <GXnA91UgJ00yospnkiRZmlPLN-phPen79vUluJ1Ne7U=.7d4bb94e-c836-4f96-ba33-047d722d470a@github.com>

On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future.
>> 
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
>> 
>>> Right now the only examples we have are in java.base. In time it might be that some other modules might need something.
>> 
>> Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from).
>>  
>>> I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link?
>> 
>> Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced  with a symlink after the JDK has been built.
>> 
>> Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build.
>> 
>> The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory.
>
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
> 
> Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.
> 
> Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

@AlanBateman Updated the patch. Please take another look. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2779073478

From sgehwolf at openjdk.org  Fri Apr  4 15:34:50 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Apr 2025 15:34:50 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
Message-ID: <ToO2AL-mkxvTwVcVgAWuhDQfDllp5tiBCvvZ0Flmyfk=.755fff9a-b306-40fe-ba8e-f79b89ec4377@github.com>

On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reboot upgradeable files approach
>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>    
>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493

It took me a while to find the magic trick to get the jlink resource file copied, so adding build-dev for their input too.

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2779101393

From xtex at envs.net  Fri Apr  4 15:35:25 2025
From: xtex at envs.net (Bingwu Zhang)
Date: Fri, 04 Apr 2025 23:35:25 +0800
Subject: javac stack overflow on loongson3 with zero variant
In-Reply-To: <5272132.GXAFRqVoOG@xtex1>
References: <4641863.LvFx2qVVIh@xtex1>
 <9ba55b96-8832-48f6-be47-52b114347928@oracle.com>
 <5272132.GXAFRqVoOG@xtex1>
Message-ID: <6261163.lOV4Wx5bFT@xtex1>

On Sunday, March 30, 2025 2:58:30?PM China Standard Time Bingwu Zhang wrote:
> I have spent a whole weekend on bisecting, due to the poor performance of
> the loongson3 processors and some recent network issues of the AOSC's build
> servers (where I do the bisect). Current progress is ~16 commits/4 steps
> remaining. Now I am testing in 5e15415cb9c...a032de2904b.

The bisect has finished, the first bad commit is:
15ae8d02eeb9 ("8319993: Update Unicode Data Files to 16.0.0 8319992: Update 
ICU4J to Version 76.1")

I checked twice that this is the first bad commit.

I have revert this commit for AOSC OS and it does fixed our loongson3 building.

-- 
Bingwu Zhang @ Fri, 04 Apr 2025 13:46:47 +0000




From ihse at openjdk.org  Fri Apr  4 15:52:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 15:52:22 GMT
Subject: RFR: 8300339: Run jtreg in the work dir
Message-ID: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>

We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

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

Commit messages:
 - 8300339: Run jtreg in the work dir

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

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

From clanger at openjdk.org  Sat Apr  5 04:51:52 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 5 Apr 2025 04:51:52 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
Message-ID: <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>

On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reboot upgradeable files approach
>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>    
>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493

Just a few fly-by findings, no full review.

I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

make/modules/jdk.jlink/Java.gmk line 29:

> 27: 
> 28: COPY += \
> 29:   $(TOPDIR)/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/upgrade_files_java.base

Wouldn't `COPY += upgrade_files_java.base` work here ?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 250:

> 248: 
> 249:     /**
> 250:      * Certain files in the a module are considered upgradeable. That is,

Suggestion:

     * Certain files in a module are considered upgradeable. That is,

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 254:

> 252:      *
> 253:      * @param resPath The resource path of the file to check for upgradeability.
> 254:      * @return {@code true} iff the file is upgradeable. {@code false} otherwise.

Suggestion:

     * @return {@code true} if the file is upgradeable. {@code false} otherwise.

test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 43:

> 41:  * @test
> 42:  * @summary Verify warnings are being produced when linking from the run-time
> 43:  *          image and files have been modified

I guess this summary has to be modified.

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

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2744611775
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696671
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696836
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029696899
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2029697243

From stuefe at openjdk.org  Sat Apr  5 05:57:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 5 Apr 2025 05:57:54 GMT
Subject: RFR: 8349467: INIT_TARGETS tab completions on "make" lost with
 JDK-8348998
In-Reply-To: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
References: <jsn81HYq7DXgsrijfwkTKQ2QnUKvhVv-4lo6h9CtYBc=.d7aef98b-2b44-43ee-9b5f-10808d0791e8@github.com>
Message-ID: <nJo10HmQVUgtyyZSs6vFQOWcyPmASg4-MfZqkxCQXf4=.7b834179-7396-4654-8c5e-6bbcc5ce9968@github.com>

On Wed, 2 Apr 2025 20:38:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab completion for all init targets, i.e. `print-modules print-targets print-configuration print-tests reconfigure pre-compare-build post-compare-build`, of which `reconfigure` was probably the hardest hit.
> 
> The solution is to move the declaration of ALL_INIT_TARGETS so it is available even for the `SKIP_SPEC=true` part of PreInit.gmk.

Many thanks, @magicus !

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

PR Comment: https://git.openjdk.org/jdk/pull/24392#issuecomment-2780254640

From aturbanov at openjdk.org  Sat Apr  5 16:48:47 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 5 Apr 2025 16:48:47 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <TtDEE-YsUyYiZqZYdvIYuw4w3-ItLVxU4Or6b29zeeQ=.848e1dd2-2df9-425a-b813-85ea1d08f3f9@github.com>

On Thu, 3 Apr 2025 14:48:58 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java line 433:

> 431:                 new Option(resources, "--syntax-highlight") {
> 432:                     @Override
> 433:                     public boolean process(String opt,  List<String> args) {

Suggestion:

                    public boolean process(String opt, List<String> args) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24417#discussion_r2029915493

From dholmes at openjdk.org  Mon Apr  7 05:15:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Apr 2025 05:15:51 GMT
Subject: RFR: 8300339: Run jtreg in the work dir
In-Reply-To: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
Message-ID: <CZ42DT3ma3GfTEJYZM5fVPPItU_UotbtF6e7tdWsmDw=.6ac66d88-5b45-4b86-857b-0e23f19f294c@github.com>

On Fri, 4 Apr 2025 14:59:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

make/RunTests.gmk line 999:

> 997: 
> 998:   $1_COMMAND_LINE := \
> 999:       cd $$($1_TEST_SUPPORT_DIR) && $$(JTREG_JAVA) \

Is TEST_SUPPORT_DIR guaranteed to be an absolute path?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24452#discussion_r2030464613

From dholmes at openjdk.org  Mon Apr  7 05:27:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Apr 2025 05:27:50 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed [v3]
In-Reply-To: <eLp2ZCtEh2Nf-y4xLoOm3Cp1sjmFYAxK4xTu6VhY8c0=.210d8799-14f6-425b-ba18-0132fbf57484@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <x-ftyHvH0lY6MWRGaP19ju5WIUrNQO699ATE4zjK_2E=.adc8b911-6b8a-49a4-9ebe-f3670c8e65d2@github.com>
 <eLp2ZCtEh2Nf-y4xLoOm3Cp1sjmFYAxK4xTu6VhY8c0=.210d8799-14f6-425b-ba18-0132fbf57484@github.com>
Message-ID: <jos22ywVF7ep_so8b4H-G77hJ6Auz5uHuphG4a69WlE=.12a1bba4-ca51-4e47-a355-57e08edf5023@github.com>

On Fri, 4 Apr 2025 13:35:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/common/modules/GensrcCommon.gmk line 45:
>> 
>>> 43: 	$$(call MakeTargetDir)
>>> 44: 	$(PRINTF) "jdk=%s\nfull=%s\nrelease=%s\n" \
>>> 45: 	    $(VERSION_NUMBER) $(VERSION_STRING) $(VERSION_SHORT) > $$@
>> 
>> Can't this just use echo like you did with the windows version elsewhere?
>
> No, there are embedded `\n` and that does not work with echo. I could split it into three consecutive lines but I don't think that would be a gain.

Ah I see. So basically the only time we actually need `printf` as far as I can see is when there are embedded newlines in the output string? We could have used `printf` without `%s` format specifiers whenever we are substituting a variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2030474527

From duke at openjdk.org  Mon Apr  7 07:11:52 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 7 Apr 2025 07:11:52 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <Q0yJJvYjLYCjKL9MGONMJiV08fP0sVPqDXC_WvadeOA=.43b5bfc9-984b-4a4c-9046-09e72d1da0b3@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

I have to respectfully disagree with your assessment for the following reasons:

- The editorconfig as defined in this PR follows the hotspot style guide and the indentation settings only apply to hotspot code.
- How does it conflict with the jcheck rules? The rules defined in this editorconfig are stricter than the jcheck rules. So jcheck could not find issues after the editorconfig rules were applied.
- Providing an editorconfig as you proposed in #24448 is not a good idea in my opinion. 
Only defining whitespace trimming will not provide real benefit to anyone. However the existing editorconfig file would conflict with locally defined ones and cause problems for developers using these files to define project specific formatting. 
So no editorconfig would be better than one representing only a small part of the core formatting rules.

I also would ask about `jcheck`. Where and how is it used. The only information I found are:
<https://openjdk.org/projects/code-tools/jcheck/> and the config file in `jdk/.jcheck`.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2782242008

From sgehwolf at openjdk.org  Mon Apr  7 08:54:52 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 08:54:52 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
 <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
Message-ID: <TNMexNLRqxUtrZXMzPWrrUwydX0QqABgZuQbbJgW4M0=.17e6cf86-b690-4931-b317-7f88b34cd4f8@github.com>

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I see that you're actively on the upgradeable files. What about #24190?

Let's keep the discussion on #24190, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2782507174

From ihse at openjdk.org  Mon Apr  7 09:58:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 09:58:00 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed [v3]
In-Reply-To: <jos22ywVF7ep_so8b4H-G77hJ6Auz5uHuphG4a69WlE=.12a1bba4-ca51-4e47-a355-57e08edf5023@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <x-ftyHvH0lY6MWRGaP19ju5WIUrNQO699ATE4zjK_2E=.adc8b911-6b8a-49a4-9ebe-f3670c8e65d2@github.com>
 <eLp2ZCtEh2Nf-y4xLoOm3Cp1sjmFYAxK4xTu6VhY8c0=.210d8799-14f6-425b-ba18-0132fbf57484@github.com>
 <jos22ywVF7ep_so8b4H-G77hJ6Auz5uHuphG4a69WlE=.12a1bba4-ca51-4e47-a355-57e08edf5023@github.com>
Message-ID: <w98GRjoPi5zsnAHijW6qrnocz0r5Wc_V1drjb4Hq7OM=.63b18393-9a11-4617-98ea-c692b3b12591@github.com>

On Mon, 7 Apr 2025 05:25:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No, there are embedded `\n` and that does not work with echo. I could split it into three consecutive lines but I don't think that would be a gain.
>
> Ah I see. So basically the only time we actually need `printf` as far as I can see is when there are embedded newlines in the output string? We could have used `printf` without `%s` format specifiers whenever we are substituting a variable.

Yes, that, or that we need additional formatting, such as "%22s" where we want to align certain fields. Embedded `\n` can in theory be replaced with multiple calls to echo, but in the end it is a matter of judgement which is to prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24415#discussion_r2030895994

From ihse at openjdk.org  Mon Apr  7 09:58:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 09:58:59 GMT
Subject: RFR: 8300339: Run jtreg in the work dir
In-Reply-To: <CZ42DT3ma3GfTEJYZM5fVPPItU_UotbtF6e7tdWsmDw=.6ac66d88-5b45-4b86-857b-0e23f19f294c@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
 <CZ42DT3ma3GfTEJYZM5fVPPItU_UotbtF6e7tdWsmDw=.6ac66d88-5b45-4b86-857b-0e23f19f294c@github.com>
Message-ID: <1Ed4vv79M5hMs_fLPQR9orGxeDARMvOYkObD6o0R4qQ=.db1a3eac-f645-4fda-a00d-266445eb6850@github.com>

On Mon, 7 Apr 2025 05:13:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.
>
> make/RunTests.gmk line 999:
> 
>> 997: 
>> 998:   $1_COMMAND_LINE := \
>> 999:       cd $$($1_TEST_SUPPORT_DIR) && $$(JTREG_JAVA) \
> 
> Is TEST_SUPPORT_DIR guaranteed to be an absolute path?

Yes. All our path variables are absolute.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24452#discussion_r2030897102

From ihse at openjdk.org  Mon Apr  7 10:04:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 10:04:04 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <Q0yJJvYjLYCjKL9MGONMJiV08fP0sVPqDXC_WvadeOA=.43b5bfc9-984b-4a4c-9046-09e72d1da0b3@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
 <Q0yJJvYjLYCjKL9MGONMJiV08fP0sVPqDXC_WvadeOA=.43b5bfc9-984b-4a4c-9046-09e72d1da0b3@github.com>
Message-ID: <sDcQP_LZVKY_Iu2JceKtYdLturnmqJ51p7Es5qKAG44=.0223c73c-e6bc-45ac-a258-ca137cbd646c@github.com>

On Mon, 7 Apr 2025 07:08:51 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> * How does it conflict with the jcheck rules? The rules defined in this editorconfig are stricter than the jcheck rules. So jcheck could not find issues after the editorconfig rules were applied.

No, it's not. The rules you propose here are stricter. You say:

[*]
trim_trailing_whitespace = true


but there is not nor have ever been such a rule for all text files in the JDK repo. This would trigger an enormous amount of spurious changes. In contrast, my suggested PR applies this only to the subset of files where we do in fact have a rule of no trailing whitespaces.

> I also would ask about `jcheck`. Where and how is it used. The only information I found are:
> https://openjdk.org/projects/code-tools/jcheck/ and the config file in `jdk/.jcheck`.

jcheck is run automatically by the Skara bots on all PRs. If jcheck reports an error (that is, a violation of enforced style rules), the PR will not be possible to integrate. 

Users can also run jcheck locally using the `git skara jcheck` command, if they have the Skara git tools installed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2782776621

From ihse at openjdk.org  Mon Apr  7 10:10:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 10:10:57 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <Q0yJJvYjLYCjKL9MGONMJiV08fP0sVPqDXC_WvadeOA=.43b5bfc9-984b-4a4c-9046-09e72d1da0b3@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
 <Q0yJJvYjLYCjKL9MGONMJiV08fP0sVPqDXC_WvadeOA=.43b5bfc9-984b-4a4c-9046-09e72d1da0b3@github.com>
Message-ID: <6BPm2Ex4oJhMn9hVRU1ulGxySbaF2Tt822tlcwx43VY=.8ca2eb48-3732-460d-a4e1-c91e45bce28f@github.com>

On Mon, 7 Apr 2025 07:08:51 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> * The editorconfig as defined in this PR follows the hotspot style guide and the indentation settings only apply to hotspot code.

Yes, you have a good point there. I included your `src/hotspot/.editorconfig` in my PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2782796610

From ihse at openjdk.org  Mon Apr  7 10:10:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 10:10:57 GMT
Subject: RFR: 8311227: Add .editorconfig [v2]
In-Reply-To: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
References: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
Message-ID: <aH92JD9gOZ3dXNK6Jk5bUbIdKJ4_U4tJH14_VyYbFnk=.f03b5c40-ae2f-421e-b61f-d4245d5884e1@github.com>

> Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing JDK-8311227.
> 
> This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck into .editorconfig format. I believe that is a better way to introduce an `.editorconfig` file into the existing JDK project.

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

  Add .editorconfig enforcing Hotspot style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24448/files
  - new: https://git.openjdk.org/jdk/pull/24448/files/d9e07e63..a5510fda

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

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

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

From ihse at openjdk.org  Mon Apr  7 10:29:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 10:29:04 GMT
Subject: RFR: 8345874: Run make doctor automatically on failed CI builds
Message-ID: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>

If there is something wrong with the build, the user can run "make doctor". That is hard to do in a CI setting. Instead, if the build environment is detected to be a CI, we should run the doctor automatically in case of a failed build.

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

Commit messages:
 - 8345874: Run make doctor automatically on failed CI builds

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

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

From sgehwolf at openjdk.org  Mon Apr  7 12:11:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:11:51 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
Message-ID: <KX7KGvAjsnJb-Dwoz-R-BdABKaVIPbR9j0DRAzOPWKs=.0f3e86fc-66c8-4d0e-9495-8c83763a8aaf@github.com>

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

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

  Review comments from Christoph

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/74b6bfe1..fe33cfd7

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

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

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

From sgehwolf at openjdk.org  Mon Apr  7 12:11:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:11:55 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
 <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
Message-ID: <BTG9AI7cUzRasec0A1g8HJVVRZrXejZEqEO7UetvZFM=.b283298f-a62f-4530-b847-1b49ee510165@github.com>

On Sat, 5 Apr 2025 04:45:00 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> make/modules/jdk.jlink/Java.gmk line 29:
> 
>> 27: 
>> 28: COPY += \
>> 29:   $(TOPDIR)/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/upgrade_files_java.base
> 
> Wouldn't `COPY += upgrade_files_java.base` work here ?

Apparently it does. Thanks for the suggestion.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 250:
> 
>> 248: 
>> 249:     /**
>> 250:      * Certain files in the a module are considered upgradeable. That is,
> 
> Suggestion:
> 
>      * Certain files in a module are considered upgradeable. That is,

Fixed.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 254:
> 
>> 252:      *
>> 253:      * @param resPath The resource path of the file to check for upgradeability.
>> 254:      * @return {@code true} iff the file is upgradeable. {@code false} otherwise.
> 
> Suggestion:
> 
>      * @return {@code true} if the file is upgradeable. {@code false} otherwise.

Fixed.

> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 43:
> 
>> 41:  * @test
>> 42:  * @summary Verify warnings are being produced when linking from the run-time
>> 43:  *          image and files have been modified
> 
> I guess this summary has to be modified.

Thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031103556
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102867
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102616
PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031102257

From clanger at openjdk.org  Mon Apr  7 12:16:56 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 12:16:56 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: <KX7KGvAjsnJb-Dwoz-R-BdABKaVIPbR9j0DRAzOPWKs=.0f3e86fc-66c8-4d0e-9495-8c83763a8aaf@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <KX7KGvAjsnJb-Dwoz-R-BdABKaVIPbR9j0DRAzOPWKs=.0f3e86fc-66c8-4d0e-9495-8c83763a8aaf@github.com>
Message-ID: <stlcwLXwu6MQ0GOduAj3lVfZombjyUuxytxgAFFCgkc=.33b2c29e-b087-417f-b7f3-cf1157d8e74f@github.com>

On Mon, 7 Apr 2025 12:11:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Christoph

test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:

> 40: /*
> 41:  * @test
> 42:  * @summary Verify that no errors are reported for files the have been

Suggestion:

 * @summary Verify that no errors are reported for files that have been

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031112907

From clanger at openjdk.org  Mon Apr  7 12:18:56 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 12:18:56 GMT
Subject: RFR: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH [v3]
In-Reply-To: <zwVepKILsP_Yhe1xDxvmlJFCobQKsbm6R_4mF6uINJA=.98970676-52f5-4f90-a2da-202420ef423d@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
 <zwVepKILsP_Yhe1xDxvmlJFCobQKsbm6R_4mF6uINJA=.98970676-52f5-4f90-a2da-202420ef423d@github.com>
Message-ID: <NhZMwA7ZApdchyK9WYcMsuFSXr4ruTg3vVIsUabXsuM=.e45b5e3e-165b-41b8-8fa8-2fa46aec8a35@github.com>

On Fri, 4 Apr 2025 09:22:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
>> 
>> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Proposal from RealCLanger to further cleanup test Test7029048

No regressions spotted, even after the test cleanup. LGTM.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24351#pullrequestreview-2746610204

From mbaesken at openjdk.org  Mon Apr  7 12:23:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 7 Apr 2025 12:23:06 GMT
Subject: RFR: 8353709: Debug symbols bundle should contain full debug files
 when building --with-external-symbols-in-bundles=public
In-Reply-To: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
Message-ID: <8-x6SEEwxmtDcWbfVYXy7FoH8QzbXJLKZZMmykByoMg=.8b3cb4e4-cb81-425c-a6f8-d3a2acd98c5a@github.com>

On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, when building with `--with-external-symbols-in-bundles=public`, the debug symbols bundle contains the stripped pdb files. It should better have the full pdb files since stripped pdbs are in the runtime image already.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24440#pullrequestreview-2746621213

From sgehwolf at openjdk.org  Mon Apr  7 12:24:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 12:24:01 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: <stlcwLXwu6MQ0GOduAj3lVfZombjyUuxytxgAFFCgkc=.33b2c29e-b087-417f-b7f3-cf1157d8e74f@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <KX7KGvAjsnJb-Dwoz-R-BdABKaVIPbR9j0DRAzOPWKs=.0f3e86fc-66c8-4d0e-9495-8c83763a8aaf@github.com>
 <stlcwLXwu6MQ0GOduAj3lVfZombjyUuxytxgAFFCgkc=.33b2c29e-b087-417f-b7f3-cf1157d8e74f@github.com>
Message-ID: <rxcALO2FqmAIrVJi96FojP_PYwkwWMZcVoDFj2Bn6RY=.c5ea4479-779d-4bd3-bb80-73028f6d4a6e@github.com>

On Mon, 7 Apr 2025 12:14:28 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from Christoph
>
> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
> 
>> 40: /*
>> 41:  * @test
>> 42:  * @summary Verify that no errors are reported for files the have been
> 
> Suggestion:
> 
>  * @summary Verify that no errors are reported for files that have been
> 
> ?

Sigh. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031123405

From jkern at openjdk.org  Mon Apr  7 12:53:55 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 7 Apr 2025 12:53:55 GMT
Subject: Integrated: 8352935: Launcher should not add $JDK/../lib to
 LD_LIBRARY_PATH
In-Reply-To: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
References: <9nVhdQrmLeDBVp0ls1p-aTrvXrcwII3phVxTQvshXzQ=.96210cd5-e3fa-454f-9b6c-d7388e86b82e@github.com>
Message-ID: <99CT0RitnWPbJEJgRb6KLx3J030x1c8CGp7wnX0kxLY=.9065328e-6445-489f-9937-46fbb4c3eff0@github.com>

On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In the JDK launcher, there is a codepath which would set/modify the LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which contains a libjvm.so.
> 
> The LD_LIBRARY_PATH is set to $JVMPATH:$JDK/lib:$JDK/../lib. The last part of this, $JDK/../lib, seems to be a remnant of times when there was a jre subfolder in a JDK deployment. So it should likely be removed.

This pull request has now been integrated.

Changeset: 9128ec61
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9128ec61df430a2eb352f58ec9799d332f7b1a10
Stats:     31 lines in 3 files changed: 2 ins; 20 del; 9 mod

8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH

Reviewed-by: clanger, ihse, jpai

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

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

From clanger at openjdk.org  Mon Apr  7 13:30:05 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 13:30:05 GMT
Subject: Integrated: 8353709: Debug symbols bundle should contain full debug
 files when building --with-external-symbols-in-bundles=public
In-Reply-To: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
References: <k82cWA1kxQ6iEn8niZt5wjo1d0EYhe3JTzzh6g0GRvM=.c3633456-03cd-4836-a379-5866954066d1@github.com>
Message-ID: <qiEYr-1BIfyi0pcZW3B3M-yK-42bIIqN1NY-dsCcTYM=.ad9872d7-87e4-44b1-b214-6e46aa04dab9@github.com>

On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Currently, when building with `--with-external-symbols-in-bundles=public`, the debug symbols bundle contains the stripped pdb files. It should better have the full pdb files since stripped pdbs are in the runtime image already.

This pull request has now been integrated.

Changeset: 60fbf73f
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60fbf73fc492ad9fff83fb4540e2d01311406287
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8353709: Debug symbols bundle should contain full debug files when building --with-external-symbols-in-bundles=public

Reviewed-by: erikj, mbaesken

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

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

From sgehwolf at openjdk.org  Mon Apr  7 13:35:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 13:35:57 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
Message-ID: <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

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

  Review v2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/fe33cfd7..89d3886d

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

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

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

From sgehwolf at openjdk.org  Mon Apr  7 13:35:58 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Apr 2025 13:35:58 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v3]
In-Reply-To: <rxcALO2FqmAIrVJi96FojP_PYwkwWMZcVoDFj2Bn6RY=.c5ea4479-779d-4bd3-bb80-73028f6d4a6e@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <KX7KGvAjsnJb-Dwoz-R-BdABKaVIPbR9j0DRAzOPWKs=.0f3e86fc-66c8-4d0e-9495-8c83763a8aaf@github.com>
 <stlcwLXwu6MQ0GOduAj3lVfZombjyUuxytxgAFFCgkc=.33b2c29e-b087-417f-b7f3-cf1157d8e74f@github.com>
 <rxcALO2FqmAIrVJi96FojP_PYwkwWMZcVoDFj2Bn6RY=.c5ea4479-779d-4bd3-bb80-73028f6d4a6e@github.com>
Message-ID: <Zq5VHsi_Dy8GeKHQi9uC4TVciizLloi0vw_y8yCO57E=.706950b1-77d3-433b-8268-5e7c636ff9f4@github.com>

On Mon, 7 Apr 2025 12:21:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42:
>> 
>>> 40: /*
>>> 41:  * @test
>>> 42:  * @summary Verify that no errors are reported for files the have been
>> 
>> Suggestion:
>> 
>>  * @summary Verify that no errors are reported for files that have been
>> 
>> ?
>
> Sigh. Thanks!

Fixed in https://github.com/openjdk/jdk/pull/24388/commits/89d3886d1803f3dc033423e59325a41c565d7a25

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031254581

From erikj at openjdk.org  Mon Apr  7 13:59:59 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 7 Apr 2025 13:59:59 GMT
Subject: RFR: 8349665: Make clean removes module-deps.gmk
In-Reply-To: <gGBWkIwQaOHN9hHyV1oaKxD0_BBmzb4sTLf_Yvj2YPc=.0243fdef-08c4-4fce-aea7-7cfba76b649e@github.com>
References: <gGBWkIwQaOHN9hHyV1oaKxD0_BBmzb4sTLf_Yvj2YPc=.0243fdef-08c4-4fce-aea7-7cfba76b649e@github.com>
Message-ID: <zzJ_cB4JX0-wr8WMnV7R5voXf0-6bJ0AXIZ10AAcWnc=.19692c2b-e2e5-42af-8bb0-eb0c0b8eb2bc@github.com>

On Thu, 3 Apr 2025 09:18:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean <some other target>` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies.

This doesn't seem to solve the issue for me. Running `make clean java.base-java` fails for me and it looks like it starts compiling all the interim langtools modules at once and getting errors like this:


Compiling up to 136 files for BUILD_java.compiler.interim
Compiling up to 360 files for BUILD_jdk.compiler.interim
Compiling up to 145 files for BUILD_jdk.internal.md.interim
Compiling up to 213 files for BUILD_jdk.javadoc.interim
Compiling up to 17 files for BUILD_JAVAC_SERVER
/Users/erik/dev/jdk/build/macosx-aarch64/buildtools/gensrc/jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim
    requires jdk.compiler.interim;

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

PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2783436352

From erikj at openjdk.org  Mon Apr  7 14:06:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 7 Apr 2025 14:06:14 GMT
Subject: RFR: 8301197: Make sure use of printf is correct and actually
 needed [v3]
In-Reply-To: <QKJ98yRxGJ6HYAX-dmqYSl39S22JXk_48CVKJDH8Gms=.829a0afe-c751-4e3b-8c37-268209a006e0@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
 <QKJ98yRxGJ6HYAX-dmqYSl39S22JXk_48CVKJDH8Gms=.829a0afe-c751-4e3b-8c37-268209a006e0@github.com>
Message-ID: <9TwPpnAX8lhW3-AEgT-tFfIHl1uHppq2nNjJdMoLVTY=.a1054319-e297-406a-b478-ef5600c89e2b@github.com>

On Fri, 4 Apr 2025 14:32:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
>> 
>> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   echo do not need escaped quotes

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24415#pullrequestreview-2746959037

From erikj at openjdk.org  Mon Apr  7 14:09:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 7 Apr 2025 14:09:11 GMT
Subject: RFR: 8300339: Run jtreg in the work dir
In-Reply-To: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
Message-ID: <M_XreIa8py8jgXxJIECpw026IHOIx8NnqScn43wPr4c=.b46abaec-79f7-4892-91dd-ccee97df0a6e@github.com>

On Fri, 4 Apr 2025 14:59:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

make/RunTests.gmk line 1000:

> 998:   $1_COMMAND_LINE := \
> 999:       cd $$($1_TEST_SUPPORT_DIR) && $$(JTREG_JAVA) \
> 1000:       $$($1_JTREG_LAUNCHER_OPTIONS) \

This this be aligned with the row below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24452#discussion_r2031327882

From erikj at openjdk.org  Mon Apr  7 14:09:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 7 Apr 2025 14:09:16 GMT
Subject: RFR: 8311227: Add .editorconfig [v2]
In-Reply-To: <aH92JD9gOZ3dXNK6Jk5bUbIdKJ4_U4tJH14_VyYbFnk=.f03b5c40-ae2f-421e-b61f-d4245d5884e1@github.com>
References: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
 <aH92JD9gOZ3dXNK6Jk5bUbIdKJ4_U4tJH14_VyYbFnk=.f03b5c40-ae2f-421e-b61f-d4245d5884e1@github.com>
Message-ID: <uMX-OScqy-o8wMFsKNvSW8ojHZX6XhOOKsmCzxuViaE=.a8f49420-b91a-423e-b78b-14d5064c12bd@github.com>

On Mon, 7 Apr 2025 10:10:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing JDK-8311227.
>> 
>> This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck into .editorconfig format. I believe that is a better way to introduce an `.editorconfig` file into the existing JDK project.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add .editorconfig enforcing Hotspot style

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24448#pullrequestreview-2746969972

From clanger at openjdk.org  Mon Apr  7 14:49:45 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 7 Apr 2025 14:49:45 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v3]
In-Reply-To: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
References: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
Message-ID: <7hBJDSmbUU_s0dAxVBrd1Tdrz8bj8BgsPAGTCImKirU=.06b0dcc1-05c2-4905-89dd-896258111c6b@github.com>

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24057/files
  - new: https://git.openjdk.org/jdk/pull/24057/files/da632788..b0f564e5

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

  Stats: 8674 lines in 195 files changed: 6185 ins; 2073 del; 416 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

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

From duke at openjdk.org  Mon Apr  7 15:48:56 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 7 Apr 2025 15:48:56 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <oS2GlBZyYUDf7ae2A6MFsjQ7_oV7fHavev6_kA-2HaY=.b91d9f82-82fa-49ff-9d27-67de4485ba17@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

I see. So you were addressing the file types specifically. I thought you had an issue with the indentation. So since you already included the indentation in the other PR I will just approve yours and close mine. 

Thanks for the explanation of jcheck.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2783820088

From duke at openjdk.org  Mon Apr  7 15:49:57 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 7 Apr 2025 15:49:57 GMT
Subject: RFR: 8311227: Add .editorconfig [v2]
In-Reply-To: <aH92JD9gOZ3dXNK6Jk5bUbIdKJ4_U4tJH14_VyYbFnk=.f03b5c40-ae2f-421e-b61f-d4245d5884e1@github.com>
References: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
 <aH92JD9gOZ3dXNK6Jk5bUbIdKJ4_U4tJH14_VyYbFnk=.f03b5c40-ae2f-421e-b61f-d4245d5884e1@github.com>
Message-ID: <47mRHRr95lDyekyONRElDlLRklT4bmdmazKdSLXm4Cw=.b670d2ee-588c-4b62-9f9c-50b9ac9b6863@github.com>

On Mon, 7 Apr 2025 10:10:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing JDK-8311227.
>> 
>> This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck into .editorconfig format. I believe that is a better way to introduce an `.editorconfig` file into the existing JDK project.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add .editorconfig enforcing Hotspot style

?

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

Marked as reviewed by dbriemann at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/24448#pullrequestreview-2747318946

From duke at openjdk.org  Mon Apr  7 15:52:06 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 7 Apr 2025 15:52:06 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
Message-ID: <9-DIvV5xUzcK1WvnpS-euxm4O2BoF7iN8omSPQ2vcuk=.79e44045-cbbf-43a8-a664-a01aeb92dc47@github.com>

On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann <duke at openjdk.org> wrote:

>> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make editorconfig hotspot specific

Closing in favor of #24448

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2783827651

From duke at openjdk.org  Mon Apr  7 15:52:07 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 7 Apr 2025 15:52:07 GMT
Subject: Withdrawn: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace
In-Reply-To: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
Message-ID: <v0zbso0xMgADASt3jnXg-_Dp5-ZTt18cUR8NBBcycSs=.2d02e621-b6d7-41d0-abef-93ae344750e2@github.com>

On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> Add an .editorconfig to define indentation, trim trailing whitespace and open curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Mon Apr  7 17:33:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 17:33:50 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
Message-ID: <EJ9hPfADEdmaWV4u6UZ8q9S6Szo9Uj7hEa8FHXs_oPw=.dbcb8ad5-3536-4707-94d1-46e1aa74ee8f@github.com>

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review v2

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:

> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
> 70:         String resourceName = String.format(DIFF_PATTERN, module);
> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);

FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2031696600

From liach at openjdk.org  Mon Apr  7 18:08:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 18:08:02 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <sKxT-hzBgXiDGNGbwzpWkRvL-Fz-JeT_niG8HaM8O70=.7afc08f6-6d3d-44d6-b2f5-30682112803e@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 94:

> 92:             if (tag.getKind() == UNKNOWN_INLINE_TAG) {
> 93:                 UnknownInlineTagTree inlineTag = (UnknownInlineTagTree) tag;
> 94:                 String[] content = inlineTag.getContent().toString().trim().split("\\s+", 2);

Just curious, does `getContent()` translate nested tags like nested `{@code}` or `{@link}`? I know the inline return tag translates those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r1937613420

From hannesw at openjdk.org  Mon Apr  7 18:08:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 7 Apr 2025 18:08:02 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <sKxT-hzBgXiDGNGbwzpWkRvL-Fz-JeT_niG8HaM8O70=.7afc08f6-6d3d-44d6-b2f5-30682112803e@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <sKxT-hzBgXiDGNGbwzpWkRvL-Fz-JeT_niG8HaM8O70=.7afc08f6-6d3d-44d6-b2f5-30682112803e@github.com>
Message-ID: <uYVzXTYrE3Nr4n-RpLpP7gOuz55cg8KE-MfmsJZzqtE=.ae112250-29a5-491d-868f-38e5dc499f66@github.com>

On Fri, 31 Jan 2025 16:58:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
>> 
>> The {@previewNote} tag uses the following syntax:
>> 
>> 
>> {@previewNote <jep-number> [preview note title]}
>> preview note text
>> {@previewNote}
>> ``` 
>> 
>> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
>> 
>> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.
>
> make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 94:
> 
>> 92:             if (tag.getKind() == UNKNOWN_INLINE_TAG) {
>> 93:                 UnknownInlineTagTree inlineTag = (UnknownInlineTagTree) tag;
>> 94:                 String[] content = inlineTag.getContent().toString().trim().split("\\s+", 2);
> 
> Just curious, does `getContent()` translate nested tags like nested `{@code}` or `{@link}`? I know the inline return tag translates those.

Because of how `DocCommentParser` is implemented, we don't have support for parsing (and rendering) nested tags in unknown inline tags (which means all inline tags using the public doclet/taglet API registered via javadoc `-taglet` option). So taglet content will only ever contain a single string of unparsed content.

The alternative would have been to build the taglet into the inernal Standard Doclet, along with its own doc comment parser, but I considered this too much effort for an internal feature with limited scope. The comments in the JBS issue have more details on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r1939162842

From hannesw at openjdk.org  Mon Apr  7 18:08:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 7 Apr 2025 18:08:02 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
Message-ID: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>

Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.

The {@previewNote} tag uses the following syntax:


{@previewNote <jep-number> [preview note title]}
preview note text
{@previewNote}
``` 

Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 

To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

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

Commit messages:
 - Add test for hidden --preview-note-tag option
 - Avoid NPE and unnecessary work
 - Merge branch 'master' into JDK-8346109
 - Minor Cleanup
 - Add PreviewNote taglet and hidden --preview-note-tag option

Changes: https://git.openjdk.org/jdk/pull/23395/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23395&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346109
  Stats: 357 lines in 8 files changed: 297 ins; 39 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23395/head:pull/23395

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

From liach at openjdk.org  Mon Apr  7 18:08:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 18:08:02 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <uYVzXTYrE3Nr4n-RpLpP7gOuz55cg8KE-MfmsJZzqtE=.ae112250-29a5-491d-868f-38e5dc499f66@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <sKxT-hzBgXiDGNGbwzpWkRvL-Fz-JeT_niG8HaM8O70=.7afc08f6-6d3d-44d6-b2f5-30682112803e@github.com>
 <uYVzXTYrE3Nr4n-RpLpP7gOuz55cg8KE-MfmsJZzqtE=.ae112250-29a5-491d-868f-38e5dc499f66@github.com>
Message-ID: <XZdV7CBM8WKQnT7s7M6pvoLAgxA7Uf0sqSutQ-c_Svg=.31eaf953-0f37-4ed5-abda-823567146d8a@github.com>

On Mon, 3 Feb 2025 10:41:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 94:
>> 
>>> 92:             if (tag.getKind() == UNKNOWN_INLINE_TAG) {
>>> 93:                 UnknownInlineTagTree inlineTag = (UnknownInlineTagTree) tag;
>>> 94:                 String[] content = inlineTag.getContent().toString().trim().split("\\s+", 2);
>> 
>> Just curious, does `getContent()` translate nested tags like nested `{@code}` or `{@link}`? I know the inline return tag translates those.
>
> Because of how `DocCommentParser` is implemented, we don't have support for parsing (and rendering) nested tags in unknown inline tags (which means all inline tags using the public doclet/taglet API registered via javadoc `-taglet` option). So taglet content will only ever contain a single string of unparsed content.
> 
> The alternative would have been to build the taglet into the inernal Standard Doclet, along with its own doc comment parser, but I considered this too much effort for an internal feature with limited scope. The comments in the JBS issue have more details on this.

Sure; I think I have requested this feature via bugs.java.com long ago. It's just that people might start using nested tags like for inline return and be surprised to find them not working.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r1978500031

From liach at openjdk.org  Mon Apr  7 18:38:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 18:38:24 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 112:

> 110:                             """);
> 111:                     return sb.toString();
> 112:                 } else {

What does this else block do? In what case can the JEP number be blank?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2031789813

From ihse at openjdk.org  Mon Apr  7 20:33:29 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 20:33:29 GMT
Subject: RFR: 8311227: Add .editorconfig so IDEs would pick up the common
 settings automatically: indent, trim trailing whitespace [v3]
In-Reply-To: <oS2GlBZyYUDf7ae2A6MFsjQ7_oV7fHavev6_kA-2HaY=.b91d9f82-82fa-49ff-9d27-67de4485ba17@github.com>
References: <bSvdPNtAUytSmRPq7NkbOaZsHyHuhzvT3GWLqldm1sg=.94cc0b43-7290-4302-b821-c33ac85a81b0@github.com>
 <T8UNdnbpZ0WKwGrSoN06W-Mpky1RB7nDQ-oW24jb-rA=.c3aef2d4-54e6-480d-89b1-dbc22dc84074@github.com>
 <oS2GlBZyYUDf7ae2A6MFsjQ7_oV7fHavev6_kA-2HaY=.b91d9f82-82fa-49ff-9d27-67de4485ba17@github.com>
Message-ID: <3FJ4nDiYuCkXnv6IlfV-5__atOBvnk5GyXjE3Wu3oe0=.f67e0cad-f237-49ce-9756-a0cf890e1c47@github.com>

On Mon, 7 Apr 2025 15:46:12 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> I thought you had an issue with the indentation.

I had an issue with indentation in the original PR, where you wanted to apply it to all files and not just Hotspot, but not the current version.

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

PR Comment: https://git.openjdk.org/jdk/pull/23693#issuecomment-2784556005

From ihse at openjdk.org  Mon Apr  7 20:35:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 20:35:21 GMT
Subject: Integrated: 8311227: Add .editorconfig
In-Reply-To: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
References: <peKE39eoiQQVcC88oSq0_II4foZmx3Pd-3ws6Ps1Bt4=.99aa4d06-fd4b-4ca5-a519-1a935ec85098@github.com>
Message-ID: <4cWakxQtHDF77OQa6gPNPp5ryTW8_kzQ6rcyIC3pyVg=.b2dd6f06-bc06-4e46-b95c-f0c46e7a952a@github.com>

On Fri, 4 Apr 2025 13:58:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing JDK-8311227.
> 
> This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck into .editorconfig format. I believe that is a better way to introduce an `.editorconfig` file into the existing JDK project.

This pull request has now been integrated.

Changeset: cebda921
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cebda921dd49cf05b521f9ab3f731dd44719b027
Stats:     10 lines in 2 files changed: 10 ins; 0 del; 0 mod

8311227: Add .editorconfig

Co-authored-by: David Briemann <david at briemann.com>
Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Apr  7 20:36:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 20:36:15 GMT
Subject: RFR: 8300339: Run jtreg in the work dir
In-Reply-To: <M_XreIa8py8jgXxJIECpw026IHOIx8NnqScn43wPr4c=.b46abaec-79f7-4892-91dd-ccee97df0a6e@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
 <M_XreIa8py8jgXxJIECpw026IHOIx8NnqScn43wPr4c=.b46abaec-79f7-4892-91dd-ccee97df0a6e@github.com>
Message-ID: <rA84YKV1x3EJOsz8NbnE4JvyOEQnv8TS7AQSoTl_qI4=.87fef41b-6cc2-45a6-88a3-5c31ad395d58@github.com>

On Mon, 7 Apr 2025 14:05:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.
>
> make/RunTests.gmk line 1000:
> 
>> 998:   $1_COMMAND_LINE := \
>> 999:       cd $$($1_TEST_SUPPORT_DIR) && $$(JTREG_JAVA) \
>> 1000:       $$($1_JTREG_LAUNCHER_OPTIONS) \
> 
> Should this be aligned with the row below?

I didn't notice that. Actually, I think it is the remaining lines that are incorrectly indented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24452#discussion_r2031968148

From ihse at openjdk.org  Mon Apr  7 20:38:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2025 20:38:15 GMT
Subject: Integrated: 8301197: Make sure use of printf is correct and actually
 needed
In-Reply-To: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
References: <-qMv-idMKxECdNf9BlAtUABnrumZwJUP2n1IW02gW68=.379aa01a-4d56-4c9d-ae25-0b73c5887a04@github.com>
Message-ID: <8RgXnDm01M41pciHsZsPCZ6oQisEwIfMBQQ7Bl_K0hc=.59371a9a-ab63-449e-ac42-b17c00f33082@github.com>

On Thu, 3 Apr 2025 13:36:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have been sloppy in our use of `printf` in make code. Most of the time, we should really use `echo` instead. If we do need to use `printf`, we should never inline make or shell variables into the formatting string, since they may contain `%` which will be interpreted as formatting. Instead, we should always use `%s` and pass the variable as an argument to `printf`.
> 
> I've checked the entire code base for usages of $PRINTF, and converted most of them to $ECHO, and made sure the remaining ones are correct. I also discovered some additional ugly stuff in relation to this, which I fixed.

This pull request has now been integrated.

Changeset: 42dc99ea
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42dc99eac16c46f1b403cce1dd14c6bda50eae70
Stats:     146 lines in 16 files changed: 17 ins; 1 del; 128 mod

8301197: Make sure use of printf is correct and actually needed

Reviewed-by: erikj

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

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

From liach at openjdk.org  Mon Apr  7 21:28:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 21:28:39 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
Message-ID: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>

Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.

Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.

Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

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

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Changes: https://git.openjdk.org/jdk/pull/24212/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310310
  Stats: 1057 lines in 5 files changed: 42 ins; 696 del; 319 mod
  Patch: https://git.openjdk.org/jdk/pull/24212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24212/head:pull/24212

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

From acobbs at openjdk.org  Mon Apr  7 21:58:09 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Apr 2025 21:58:09 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <mYewUnMcP4Tm17JWD3E2xmwKrHpJoIYjxlSlTM8qvvw=.1880f465-7d38-4e40-891b-78c319c408f7@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

Refactoring awesomeness ratio:

1011 deletions
357 additions
RAR: 2.83

Impressive :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784715392

From liach at openjdk.org  Mon Apr  7 21:58:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 21:58:10 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <KKr_d6neeEu5hRAYHvFTzdMnN37a5dcNXcRGgsuKGwU=.0d09facc-4ff5-491a-8826-6fd822cad160@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

No worries - we will delete the whole com.sun.tools.classfile package, which will be another 10k+ lines removed ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784718454

From liach at openjdk.org  Mon Apr  7 22:13:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 22:13:10 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <B8-m1oa7Mrdug8w1gewGDZzFWVrOjn2kRcVnXBCrL7k=.cd33cdcd-1376-43cc-9c54-28f532e5cdb8@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

@nizarbenalla Can you help run CreateSymbols from this patch and compare the results with baseline?

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2784744589

From duke at openjdk.org  Tue Apr  8 03:31:14 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 8 Apr 2025 03:31:14 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v3]
In-Reply-To: <COFhKWNb4zLCc9CTxLYFnIwQTEsPwrkl7oMvk5Xz2jk=.9c7f1b3f-bd7a-4e57-b620-2498f34035da@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <IwWrBTrctay8G5JXqhcEtXnU5oQuLiTtvAfITxIR8Mo=.4708f3f9-36da-4d17-97ba-c7d1c5adf073@github.com>
 <COFhKWNb4zLCc9CTxLYFnIwQTEsPwrkl7oMvk5Xz2jk=.9c7f1b3f-bd7a-4e57-b620-2498f34035da@github.com>
Message-ID: <ZPDon4_sRvOld6r0lmiNcPRvi9h_xKgIM6dbVPCbLkc=.d3793715-09e0-4310-a85a-38021ddbbcbb@github.com>

On Fri, 4 Apr 2025 14:28:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It might still make sense to document that to cross-compile to aarch64, the flag `--openjdk-target=aarch64-unknown-cygwin` should be used -- that is in no way obvious or trivial to figure out.

ok, I'll leave the cross-compilation instructions in place.

> I think what you are talking about is the fact that, at least currently, the BuildTools distribution of Visual Studio do not include aarch64-hosted compilers, so to be able to run native builds without the Prism emulation, you need to install the full Visual Studio, including the IDE. This too might be worth documenting, with the caveat that it applies currently but might change in the future.

taking another look at the build tools, will update this docs PR by end of week

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2785130810

From hannesw at openjdk.org  Tue Apr  8 06:54:15 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 06:54:15 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
Message-ID: <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>

On Mon, 7 Apr 2025 18:32:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
>> 
>> The {@previewNote} tag uses the following syntax:
>> 
>> 
>> {@previewNote <jep-number> [preview note title]}
>> preview note text
>> {@previewNote}
>> ``` 
>> 
>> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
>> 
>> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.
>
> make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 112:
> 
>> 110:                             """);
>> 111:                     return sb.toString();
>> 112:                 } else {
> 
> What does this else block do? In what case can the JEP number be blank?

The else block generates the closing tag for the note. As you see in the PR description, the tag syntax resembles HTML open/close tags. This is a compromise to be able to locate the note within the description (which isn't possible with block tags), and being able to use rich content in the note without being required to writing a dedicated tag parser and rendering code. (I also happen to find this syntax easier to read than a custom inline tag, which would require additional rules to separate meta data from note content.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2032506967

From duke at openjdk.org  Tue Apr  8 11:32:17 2025
From: duke at openjdk.org (snake66)
Date: Tue, 8 Apr 2025 11:32:17 GMT
Subject: RFR: 8353580: libjpeg is not found if not installed in system
 directories
In-Reply-To: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
References: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
Message-ID: <w_SGSEZyaVQZlEv0mjMaRy3Cy2I9EjFX_6mCSR5XbfE=.c57453e5-2f51-4bd2-878d-e9692e6161df@github.com>

On Thu, 3 Apr 2025 07:59:26 GMT, snake66 <duke at openjdk.org> wrote:

> The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.
> 
> This work is sponsored by The FreeBSD Foundation

Anybody want to sponsor this change? Would be much appreciated. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24403#issuecomment-2786127306

From duke at openjdk.org  Tue Apr  8 11:32:19 2025
From: duke at openjdk.org (snake66)
Date: Tue, 8 Apr 2025 11:32:19 GMT
Subject: RFR: 8353573: System giflib not found by configure if it's not in
 system directories
In-Reply-To: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
References: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
Message-ID: <t90TD2z7Z6edHn5XxGCdC0KLgYJE-LbRH0IWxIyfFd4=.471f99f9-fe0f-4183-ae16-21207235ffa9@github.com>

On Thu, 3 Apr 2025 08:04:50 GMT, snake66 <duke at openjdk.org> wrote:

> The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script. 
> 
> This work is sponsored by The FreeBSD Foundation

Anybody care to sponsor this change? Would be much appreciated. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24404#issuecomment-2786129621

From duke at openjdk.org  Tue Apr  8 12:43:31 2025
From: duke at openjdk.org (snake66)
Date: Tue, 8 Apr 2025 12:43:31 GMT
Subject: Integrated: 8353580: libjpeg is not found if not installed in system
 directories
In-Reply-To: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
References: <hNO-m6FOnflfwyWtCmTgSw_k-k1fXwayMu28tu8jg5U=.23dcb841-9fc1-43e3-8793-b4668fc33793@github.com>
Message-ID: <VmgBAkkN-D_iyEG8fREdeog-Isgm8d88TWBWNdrNCrg=.fbfcfbf2-aaf0-4637-b37f-f17e68ca344a@github.com>

On Thu, 3 Apr 2025 07:59:26 GMT, snake66 <duke at openjdk.org> wrote:

> The autoconf scrips fail to find libjpeg on systems where it's not installed in the default system include and library directories. It should check for the pkgconfig in these cases.
> 
> This work is sponsored by The FreeBSD Foundation

This pull request has now been integrated.

Changeset: 3d24f1a3
Author:    Harald Eilertsen <haraldei at anduin.net>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d24f1a38280fd7f40148399c1ae2f3bd20763e5
Stats:     17 lines in 2 files changed: 11 ins; 0 del; 6 mod

8353580: libjpeg is not found if not installed in system directories

Reviewed-by: erikj

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

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

From duke at openjdk.org  Tue Apr  8 12:44:23 2025
From: duke at openjdk.org (snake66)
Date: Tue, 8 Apr 2025 12:44:23 GMT
Subject: Integrated: 8353573: System giflib not found by configure if it's not
 in system directories
In-Reply-To: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
References: <SK1EPJwrrXc8yU40sW1jWhJmqjatsevozm8TFAXtKs8=.26f357bf-6124-48a6-8b53-8555890f5e7a@github.com>
Message-ID: <gWdxFmX0fb86XXLZvuPxanKrDG3nzIw8FusFg1-CECI=.27fd4aa4-75d6-4cec-8d49-b095fef40b20@github.com>

On Thu, 3 Apr 2025 08:04:50 GMT, snake66 <duke at openjdk.org> wrote:

> The configure script is not able to pick up the giflib installed via system packages if it's not located in the system include and lib directories. Since giflib does not provide a pkgconfig, arguments to specify the location of the include and library files needs to be added to the configure script. 
> 
> This work is sponsored by The FreeBSD Foundation

This pull request has now been integrated.

Changeset: b3751b90
Author:    Harald Eilertsen <haraldei at anduin.net>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3751b90f6f5406fb78f0f9a01f0337a64021dfc
Stats:     39 lines in 2 files changed: 35 ins; 0 del; 4 mod

8353573: System giflib not found by configure if it's not in system directories

Reviewed-by: erikj

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

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

From nbenalla at openjdk.org  Tue Apr  8 13:08:24 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 8 Apr 2025 13:08:24 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <SwGsfE4lv_p9FmwYxFE5-lNRB3Xy0rY6l2K2mixr3OQ=.43a540c1-fccc-4182-84c1-1406ee5ec6a3@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

I compared the results with baseline a few times and they seem identical. 
I checked out the JDK repo at an earlier point and followed the same steps I used to create https://github.com/openjdk/jdk/pull/22867 and the result was identical.

Great work!

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2786377026

From sgehwolf at openjdk.org  Tue Apr  8 13:34:22 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 8 Apr 2025 13:34:22 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <EJ9hPfADEdmaWV4u6UZ8q9S6Szo9Uj7hEa8FHXs_oPw=.dbcb8ad5-3536-4707-94d1-46e1aa74ee8f@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <EJ9hPfADEdmaWV4u6UZ8q9S6Szo9Uj7hEa8FHXs_oPw=.dbcb8ad5-3536-4707-94d1-46e1aa74ee8f@github.com>
Message-ID: <tdUr_l_21OWfwoPvUZh9E0iu8O95Tqchwyb1PaMYMR8=.a5ed7608-cf36-487e-ada1-48f6b45e305c@github.com>

On Mon, 7 Apr 2025 17:30:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review v2
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:
> 
>> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
>> 70:         String resourceName = String.format(DIFF_PATTERN, module);
>> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);
> 
> FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.

It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2033202346

From ihse at openjdk.org  Tue Apr  8 14:25:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 14:25:03 GMT
Subject: RFR: 8300339: Run jtreg in the work dir [v2]
In-Reply-To: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
Message-ID: <LlOISYr72b4FcYgi07UiSIEut9xyVLgZRkAvuyETnVg=.a0081294-6dee-4d8e-9f2f-8033bba47419@github.com>

> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

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

  Adjust indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24452/files
  - new: https://git.openjdk.org/jdk/pull/24452/files/d2bbfe3a..90a76851

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

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

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

From ihse at openjdk.org  Tue Apr  8 14:31:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 14:31:38 GMT
Subject: RFR: 8300339: Run jtreg in the work dir [v3]
In-Reply-To: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
Message-ID: <E8X5hyZYRblAO0iSt20m6teywANaytn3KkoHSlS9ios=.6b331405-b3dc-4dd2-97d5-4b5008b7e165@github.com>

> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

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

  Fix indentation and separate out arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24452/files
  - new: https://git.openjdk.org/jdk/pull/24452/files/90a76851..a819d701

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

  Stats: 31 lines in 1 file changed: 16 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24452/head:pull/24452

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

From ihse at openjdk.org  Tue Apr  8 14:31:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 14:31:38 GMT
Subject: RFR: 8300339: Run jtreg in the work dir [v3]
In-Reply-To: <rA84YKV1x3EJOsz8NbnE4JvyOEQnv8TS7AQSoTl_qI4=.87fef41b-6cc2-45a6-88a3-5c31ad395d58@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
 <M_XreIa8py8jgXxJIECpw026IHOIx8NnqScn43wPr4c=.b46abaec-79f7-4892-91dd-ccee97df0a6e@github.com>
 <rA84YKV1x3EJOsz8NbnE4JvyOEQnv8TS7AQSoTl_qI4=.87fef41b-6cc2-45a6-88a3-5c31ad395d58@github.com>
Message-ID: <F_KQDYAatWyEw81YKMIsHK4jEuOa_MkjZlBdICb90Ek=.0749a99a-881c-4410-b703-b2efd018cd35@github.com>

On Mon, 7 Apr 2025 20:33:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/RunTests.gmk line 1000:
>> 
>>> 998:   $1_COMMAND_LINE := \
>>> 999:       cd $$($1_TEST_SUPPORT_DIR) && $$(JTREG_JAVA) \
>>> 1000:       $$($1_JTREG_LAUNCHER_OPTIONS) \
>> 
>> Should this be aligned with the row below?
>
> I didn't notice that. Actually, I think it is the remaining lines that are incorrectly indented.

With some more context, I see that the original author tried to separate the jtreg arguments from the additional structure needing to execute things properly in make. I made this more explicit by extracting the arguments to a separate variable, which led to more natural indentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24452#discussion_r2033331769

From mbaesken at openjdk.org  Tue Apr  8 14:46:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Apr 2025 14:46:30 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@github.com>
Message-ID: <-ut2L3mbuwzJxlZJGiGyhMl7_HCpd1QX-kuFOX8m1Lc=.38fc5800-855a-49cd-9f3e-3ccadd19885b@github.com>

On Tue, 1 Apr 2025 11:59:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It would be interesting to also see how compilation times varies with optimization level. At least some kind of hint if HIGHEST is like 2x slower than LOW, or if SIZE is slower than LOW at all, etc. The relative speed difference is interesting, but so is it in absolute terms. If a library takes 0.5 seconds on LOW but 1.1 seconds on HIGH on a particular system, it is unlikely to matter much to overall build time anywhere. But if it goes from 15s to 30s on a fast machine, it might be a problem if such performance regressions stack up, especially on slower machines (which includes the ones running GHA).

This is what I got from my Linux x86_64 system using gcc 13.2.0 devkit (opt build). Note that the build operates on a relatively slow filer, this will slow the build time somewhat  but that is true for all  opt-levels.


rm -rf  ./support/modules_libs/jdk.jdwp.agent/libjdwp.so  ./jdk/lib/libjdwp.so   ./support/native/jdk.jdwp.agent/libjdwp
time make jdk.jdwp.agent-libs-only  JOBS=1



gave me these times 

**default (LOW)**
real    0m15.661s
user    0m8.763s
sys     0m2.012s

**HIGHEST**
real    0m15.201s
user    0m9.005s
sys	    0m2.003s

**SIZE**
real    0m14.263s
user    0m7.905s
sys     0m1.891s

So it looks like SIZE is a little faster than the other, and LOW  and  HIGHEST are rather similar.
LOW is `-O2` on Linuxx86_64 and HIGHEST is `-O3` , those are maybe rather similar  (LOW is a bit misleading because `-O2` is not really that 'low' the gcc docu says about it  : 'Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff.').

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2786694168

From ihse at openjdk.org  Tue Apr  8 14:56:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 14:56:59 GMT
Subject: RFR: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
Message-ID: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>

In libraries.m4, there is a long list of known 32-bit CPU architectures as a condition for using libatomic with zero. We should just check the address size instead.

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

Commit messages:
 - 8317012: Explicitly check for 32-bit word size for using libatomic with zero

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

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

From ihse at openjdk.org  Tue Apr  8 15:00:28 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 15:00:28 GMT
Subject: RFR: 8340185: Use make -k on GHA to catch more build errors
Message-ID: <jvKwuLsS9lw0c5vs0R_XwKySmwjnZSBNbiCDVV2-mIQ=.15d511a5-532c-4e7d-8355-c01ae49bd98e@github.com>

When building the JDK on GHA, we should use `make -k` to continue building as much as possible in case of failure, to avoid having developers resubmitting one fix after another.

The additional cost of continuing to build even in a failed build is pretty small compared to the overhead of having to resubmit the entire GHA several times.

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

Commit messages:
 - 8340185: Use make -k on GHA to catch more build errors

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

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

From shade at openjdk.org  Tue Apr  8 15:16:19 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Apr 2025 15:16:19 GMT
Subject: RFR: 8340185: Use make -k on GHA to catch more build errors
In-Reply-To: <jvKwuLsS9lw0c5vs0R_XwKySmwjnZSBNbiCDVV2-mIQ=.15d511a5-532c-4e7d-8355-c01ae49bd98e@github.com>
References: <jvKwuLsS9lw0c5vs0R_XwKySmwjnZSBNbiCDVV2-mIQ=.15d511a5-532c-4e7d-8355-c01ae49bd98e@github.com>
Message-ID: <y-s6SqCFD9T77lHAcAXqQktQUWS6rpaasBWcOxWE7AY=.6e744f1f-8e80-4d5d-b77f-52ade78eb588@github.com>

On Tue, 8 Apr 2025 14:36:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When building the JDK on GHA, we should use `make -k` to continue building as much as possible in case of failure, to avoid having developers resubmitting one fix after another.
> 
> The additional cost of continuing to build even in a failed build is pretty small compared to the overhead of having to resubmit the entire GHA several times.

Yes, good idea!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24512#pullrequestreview-2750373228

From shade at openjdk.org  Tue Apr  8 15:20:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Apr 2025 15:20:24 GMT
Subject: RFR: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
In-Reply-To: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
References: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
Message-ID: <zmMOW0BTV2a_boK3ic6_JvCosEdVmWnklwN71zSGE4w=.fb6e2726-f62f-425c-bbb7-57f37ebc9736@github.com>

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

> In libraries.m4, there is a long list of known 32-bit CPU architectures as a condition for using libatomic with zero. We should just check the address size instead.

Comprehension check: we get bitness from arch itself somewhere earlier, right? `PLATFORM_EXTRACT_VARS_FROM_CPU` looks to be doing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24515#issuecomment-2786804550

From erikj at openjdk.org  Tue Apr  8 16:21:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Apr 2025 16:21:22 GMT
Subject: RFR: 8300339: Run jtreg in the work dir [v3]
In-Reply-To: <E8X5hyZYRblAO0iSt20m6teywANaytn3KkoHSlS9ios=.6b331405-b3dc-4dd2-97d5-4b5008b7e165@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
 <E8X5hyZYRblAO0iSt20m6teywANaytn3KkoHSlS9ios=.6b331405-b3dc-4dd2-97d5-4b5008b7e165@github.com>
Message-ID: <rA6C3wTkg7YB7OK_fvlTsX5EP-MErNRWqfEeMXRVOkI=.d2c44c4e-f0e9-4bc5-b9a8-3ee1509d4cdd@github.com>

On Tue, 8 Apr 2025 14:31:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and separate out arguments

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24452#pullrequestreview-2750613283

From ihse at openjdk.org  Tue Apr  8 16:58:25 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 16:58:25 GMT
Subject: Integrated: 8300339: Run jtreg in the work dir
In-Reply-To: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
References: <9Gi7o3sZIDnUDZ8khOoUJnvyPDrgVp3KjysKMWQ45BQ=.6d99c733-d73a-45fb-a5fe-53a2998a4210@github.com>
Message-ID: <6vXxF2aOkWVHmFdj1NKQyFqG2lnf1aHb9JGt-U5FT3I=.a9525bd7-f689-4346-b954-565ac76b24a4@github.com>

On Fri, 4 Apr 2025 14:59:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We had a test setup failure in our distributed test system where the process running jtreg crashed. This caused the hs_err file to end up in the root of the source tree. Dropping crash files in the source tree is bad practice and makes it harder to find such files. We should change the current working directory to the work/output dir before launching jtreg to help avoid this situation in the future.

This pull request has now been integrated.

Changeset: bd73a064
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd73a0641615d743663ef652bc1f27305af1517b
Stats:     30 lines in 1 file changed: 16 ins; 13 del; 1 mod

8300339: Run jtreg in the work dir

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Tue Apr  8 16:59:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 16:59:26 GMT
Subject: Integrated: 8340185: Use make -k on GHA to catch more build errors
In-Reply-To: <jvKwuLsS9lw0c5vs0R_XwKySmwjnZSBNbiCDVV2-mIQ=.15d511a5-532c-4e7d-8355-c01ae49bd98e@github.com>
References: <jvKwuLsS9lw0c5vs0R_XwKySmwjnZSBNbiCDVV2-mIQ=.15d511a5-532c-4e7d-8355-c01ae49bd98e@github.com>
Message-ID: <evgogb7J-JChFjpjdkDq1Wj_E5r9gjULvjmaJoCx-u4=.cf4c8f90-892d-4b89-9ed4-c21aa4b964e9@github.com>

On Tue, 8 Apr 2025 14:36:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When building the JDK on GHA, we should use `make -k` to continue building as much as possible in case of failure, to avoid having developers resubmitting one fix after another.
> 
> The additional cost of continuing to build even in a failed build is pretty small compared to the overhead of having to resubmit the entire GHA several times.

This pull request has now been integrated.

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

8340185: Use make -k on GHA to catch more build errors

Reviewed-by: shade

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

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

From erikj at openjdk.org  Tue Apr  8 17:20:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Apr 2025 17:20:12 GMT
Subject: RFR: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
In-Reply-To: <zmMOW0BTV2a_boK3ic6_JvCosEdVmWnklwN71zSGE4w=.fb6e2726-f62f-425c-bbb7-57f37ebc9736@github.com>
References: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
 <zmMOW0BTV2a_boK3ic6_JvCosEdVmWnklwN71zSGE4w=.fb6e2726-f62f-425c-bbb7-57f37ebc9736@github.com>
Message-ID: <kQm_e4KsmgUWfpg5lJgdVjArRiwhIIh3jUeS5xRXEIM=.7e83c73d-d69e-4b87-b848-b8c5f4d5da7d@github.com>

On Tue, 8 Apr 2025 15:17:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Comprehension check: we get bitness from arch itself somewhere earlier, right? `PLATFORM_EXTRACT_VARS_FROM_CPU` looks to be doing this.

Yes, that's correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/24515#issuecomment-2787148097

From erikj at openjdk.org  Tue Apr  8 17:20:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Apr 2025 17:20:11 GMT
Subject: RFR: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
In-Reply-To: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
References: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
Message-ID: <jLo5ZhPSwCE3sjtfcUtEEs6TIrcPbqu-Q-h09kGwTe8=.1211baf3-6a05-431e-bb41-79f3a640787e@github.com>

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

> In libraries.m4, there is a long list of known 32-bit CPU architectures as a condition for using libatomic with zero. We should just check the address size instead.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24515#pullrequestreview-2750821448

From shade at openjdk.org  Tue Apr  8 17:24:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Apr 2025 17:24:20 GMT
Subject: RFR: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
In-Reply-To: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
References: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
Message-ID: <Q2c63n-rdoovXAvH288jHOuXhjE2FX-d5sbzBFBjHzE=.47102d31-e1f9-46af-8759-b08176bc20ff@github.com>

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

> In libraries.m4, there is a long list of known 32-bit CPU architectures as a condition for using libatomic with zero. We should just check the address size instead.

All right then.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24515#pullrequestreview-2750841414

From ihse at openjdk.org  Tue Apr  8 17:42:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 17:42:51 GMT
Subject: RFR: 8187520: Add --disable-javac-warnings-as-errors configure option
Message-ID: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>

Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.

The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

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

Commit messages:
 - 8187520: Add --disable-javac-warnings-as-errors configure option

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

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

From ihse at openjdk.org  Tue Apr  8 17:42:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 17:42:52 GMT
Subject: RFR: 8187520: Add --disable-javac-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <g1lOFiY6AW6rZ0B-ut4-Zvg5KYh3Iix5FBEia3ScRtI=.570f4255-e3f9-44df-bb73-dfd9f3c3539d@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

Note that this PR removes the undocumented method of setting `JAVA_WARNINGS_ARE_ERRORS` on the command line. Since this was never documented nor very well-known by developers, I don't see a need to make any transition arrangements.

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

PR Comment: https://git.openjdk.org/jdk/pull/24486#issuecomment-2782966210

From ihse at openjdk.org  Tue Apr  8 17:43:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 17:43:16 GMT
Subject: Integrated: 8317012: Explicitly check for 32-bit word size for using
 libatomic with zero
In-Reply-To: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
References: <U8LeEJOs6fc5xkUEzMUwDOeOPngK6uWcxED4FGtpx8E=.f809e403-33e6-484c-a56d-6826e606f965@github.com>
Message-ID: <3wFCrgsoMX1jtZqwh93T9Jd4r0Pgm-AcYgwTbGy76n8=.1f1a3aab-13bb-418c-b0e8-0d3794d354b8@github.com>

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

> In libraries.m4, there is a long list of known 32-bit CPU architectures as a condition for using libatomic with zero. We should just check the address size instead.

This pull request has now been integrated.

Changeset: 689d73a3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/689d73a30d0701693ad86be164e4406effa11f2e
Stats:     8 lines in 1 file changed: 0 ins; 6 del; 2 mod

8317012: Explicitly check for 32-bit word size for using libatomic with zero

Reviewed-by: erikj, shade

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

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

From liach at openjdk.org  Tue Apr  8 18:11:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 18:11:21 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
 <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>
Message-ID: <OMy7sMBk684K5PEPRaXr7Z2F6ugHdOlad4iyxuMphrY=.474a4fd3-8ef1-4638-9fb1-3bbb513c0f45@github.com>

On Tue, 8 Apr 2025 06:51:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/taglet/PreviewNote.java line 112:
>> 
>>> 110:                             """);
>>> 111:                     return sb.toString();
>>> 112:                 } else {
>> 
>> What does this else block do? In what case can the JEP number be blank?
>
> The else block generates the closing tag for the note. As you see in the PR description, the tag syntax resembles HTML open/close tags. This is a compromise to be able to locate the note within the description (which isn't possible with block tags), and being able to use rich content in the note without being required to writing a dedicated tag parser and rendering code. (I also happen to find this syntax easier to read than a custom inline tag, which would require additional rules to separate meta data from note content.)

Such usage should be reflected in `testPreviewNoteTag`, which currently does not use it as open/close tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2033775847

From hannesw at openjdk.org  Tue Apr  8 18:22:12 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 8 Apr 2025 18:22:12 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <OMy7sMBk684K5PEPRaXr7Z2F6ugHdOlad4iyxuMphrY=.474a4fd3-8ef1-4638-9fb1-3bbb513c0f45@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
 <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>
 <OMy7sMBk684K5PEPRaXr7Z2F6ugHdOlad4iyxuMphrY=.474a4fd3-8ef1-4638-9fb1-3bbb513c0f45@github.com>
Message-ID: <Vh2hgbQchDfdIPcIiF1Ab2Af8tdRRDtgxv7eIqcx9y4=.007e265a-ff8a-47d9-9176-5e088a843b06@github.com>

On Tue, 8 Apr 2025 18:08:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The else block generates the closing tag for the note. As you see in the PR description, the tag syntax resembles HTML open/close tags. This is a compromise to be able to locate the note within the description (which isn't possible with block tags), and being able to use rich content in the note without being required to writing a dedicated tag parser and rendering code. (I also happen to find this syntax easier to read than a custom inline tag, which would require additional rules to separate meta data from note content.)
>
> Such usage should be reflected in `testPreviewNoteTag`, which currently does not use it as open/close tags.

The problem is the Taglet class is part of the build system, and I don't think we have a way to test these build classes (I coulndn't find any tests for the other build Taglets). I could replicate the Taglet class in the test, but that doesn't seem like a good solution either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2033795505

From liach at openjdk.org  Tue Apr  8 18:35:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 18:35:11 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <Vh2hgbQchDfdIPcIiF1Ab2Af8tdRRDtgxv7eIqcx9y4=.007e265a-ff8a-47d9-9176-5e088a843b06@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
 <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>
 <OMy7sMBk684K5PEPRaXr7Z2F6ugHdOlad4iyxuMphrY=.474a4fd3-8ef1-4638-9fb1-3bbb513c0f45@github.com>
 <Vh2hgbQchDfdIPcIiF1Ab2Af8tdRRDtgxv7eIqcx9y4=.007e265a-ff8a-47d9-9176-5e088a843b06@github.com>
Message-ID: <3g1znPCkrXwFs7KpaCvr6A6bfVyt68phdhDnNZRmluU=.61114b79-03ff-4be4-a0a0-f92c985eb3e2@github.com>

On Tue, 8 Apr 2025 18:19:21 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Such usage should be reflected in `testPreviewNoteTag`, which currently does not use it as open/close tags.
>
> The problem is the Taglet class is part of the build system, and I don't think we have a way to test these build classes (I coulndn't find any tests for the other build Taglets). I could replicate the Taglet class in the test, but that doesn't seem like a good solution either.

Can we have a usage example of this tag somewhere then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2033820887

From ihse at openjdk.org  Tue Apr  8 18:51:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 18:51:40 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
Message-ID: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>

Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

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

Commit messages:
 - Also fix RepGen
 - Update with correct syntax + debug support
 - 8282493: Add --with-jcov-modules convenience option

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

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

From ihse at openjdk.org  Tue Apr  8 18:54:14 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Apr 2025 18:54:14 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
Message-ID: <qY09e7Wgp83--_Sa580JFcrC2Vzh4PPWwV2PId3S9uw=.27d602d8-d90e-49a5-b9a1-dffcac67a396@github.com>

On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

@shurymury I believe you are the one that originally requested this functionality. (The JBS issue is opened by me and does not mention you, but I think I created it after an offline conversation with you).

Can you please have a look at this, and verify that it works like intended?

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

PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2787386009

From liach at openjdk.org  Tue Apr  8 19:37:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 19:37:19 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <UhrQg2oHygSQsDA2rZQgu-w0OAXBxYFtEYav8Y6wqBg=.837488fc-130b-468a-b2fa-abacb159935c@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

Tests tier 1-3 all pass (except a tier 2 test already fixed by 8353945)

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2787478035

From erikj at openjdk.org  Tue Apr  8 19:38:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Apr 2025 19:38:22 GMT
Subject: RFR: 8187520: Add --disable-javac-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <0rTwpowdNjeAV0bQzPg1jXSJ-qMcs-IMDvU8_HfnKI0=.6eaf0be8-0507-4818-b9fa-7235d4d6d227@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24486#pullrequestreview-2751196933

From erikj at openjdk.org  Tue Apr  8 19:46:10 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Apr 2025 19:46:10 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
Message-ID: <YEeZMcaEa1Z0yPX5Y71y2KsNn22MWooMXTvK1p5bZDM=.b8e03ab4-b817-4aec-a3dc-a4d24a4c02cb@github.com>

On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

Marked as reviewed by erikj (Reviewer).

make/Coverage.gmk line 42:

> 40: JCOV_TEMP := $(JCOV_SUPPORT_DIR)/temp
> 41: 
> 42: ifneq ($(JCOV_MODULES), )

Is this redundant conditional done on purpose?

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

PR Review: https://git.openjdk.org/jdk/pull/24481#pullrequestreview-2751203268
PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2033908828

From liach at openjdk.org  Tue Apr  8 20:33:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:33:33 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24212/files
  - new: https://git.openjdk.org/jdk/pull/24212/files/df57ca1e..e3d1a4ea

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

  Stats: 2874 lines in 118 files changed: 2267 ins; 175 del; 432 mod
  Patch: https://git.openjdk.org/jdk/pull/24212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24212/head:pull/24212

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

From liach at openjdk.org  Tue Apr  8 20:40:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 20:40:53 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
Message-ID: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>

With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.

Testing: built locally, running tier 1-3 tests

Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

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

Depends on: https://git.openjdk.org/jdk/pull/24212

Commit messages:
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352748
  Stats: 11072 lines in 74 files changed: 42 ins; 10705 del; 325 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

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

From bpb at openjdk.org  Tue Apr  8 22:56:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Apr 2025 22:56:53 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v12]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <KE7Ucy7Riw8XDq2Lqh901Dhw4RwsTY7E3nc18LoCgrY=.727216de-4084-43d3-8437-c9644bc72fbd@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5b42c46b...3e1e15dc

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=11
  Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From hannesw at openjdk.org  Wed Apr  9 00:49:45 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 9 Apr 2025 00:49:45 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v2]
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <uIqymWofDlSvlc1rLq6IzdjykZWKuR5qislyRa9hy3s=.17005ac9-23ce-4137-9a47-54311b8fe288@github.com>

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Adjust CSS spacings, remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24417/files
  - new: https://git.openjdk.org/jdk/pull/24417/files/dd766914..2700131d

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

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

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

From hannesw at openjdk.org  Wed Apr  9 01:00:56 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 9 Apr 2025 01:00:56 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v3]
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <DbOnNgfKKY7rTD9mULmqTL0BdCiPTsPzrJEDDbyg474=.1455d242-9796-4efd-b215-cf92ab1988f2@github.com>

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

Hannes Walln?fer 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 'master' into JDK-8348282
 - Adjust CSS spacings, remove whitespace
 - Remove trailing spaces
 - Brigthen variable color
 - Fix regular expression for type arguments
 - 8348282: Add option for syntax highlighting in javadoc snippets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24417/files
  - new: https://git.openjdk.org/jdk/pull/24417/files/2700131d..af50d173

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

  Stats: 21918 lines in 734 files changed: 15501 ins; 4680 del; 1737 mod
  Patch: https://git.openjdk.org/jdk/pull/24417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24417/head:pull/24417

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

From dholmes at openjdk.org  Wed Apr  9 01:01:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Apr 2025 01:01:23 GMT
Subject: RFR: 8354088: [BACKOUT]  Run jtreg in the work dir
Message-ID: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>

https://github.com/dholmes-ora/jdk/pull/new/8354088-backout

This reverts commit bd73a0641615d743663ef652bc1f27305af1517b.

It causes problems with paths to ProblemList files no longer being correct.

Re-tested tier3

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

Commit messages:
 - Revert "8300339: Run jtreg in the work dir"

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

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

From darcy at openjdk.org  Wed Apr  9 01:29:26 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 9 Apr 2025 01:29:26 GMT
Subject: RFR: 8354088: [BACKOUT]  Run jtreg in the work dir
In-Reply-To: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
References: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
Message-ID: <0orWuc90j-dzUryymy0jlWkevGgQtFysUnrWURV2Y5c=.2310f8de-4ee6-4180-b1cb-932925bfaec3@github.com>

On Wed, 9 Apr 2025 00:54:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> https://github.com/dholmes-ora/jdk/pull/new/8354088-backout
> 
> This reverts commit bd73a0641615d743663ef652bc1f27305af1517b.
> 
> It causes problems with paths to ProblemList files no longer being correct.
> 
> Re-tested tier3

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24531#pullrequestreview-2751818189

From iris at openjdk.org  Wed Apr  9 01:42:47 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 9 Apr 2025 01:42:47 GMT
Subject: RFR: 8354088: [BACKOUT]  Run jtreg in the work dir
In-Reply-To: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
References: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
Message-ID: <xx4UczRbdB048XwEa4ZT5K6SYjB70CwHJWpAwJFi6KA=.81996089-6ef0-4096-aa38-c765b3be6c3c@github.com>

On Wed, 9 Apr 2025 00:54:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> https://github.com/dholmes-ora/jdk/pull/new/8354088-backout
> 
> This reverts commit bd73a0641615d743663ef652bc1f27305af1517b.
> 
> It causes problems with paths to ProblemList files no longer being correct.
> 
> Re-tested tier3

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24531#pullrequestreview-2751829519

From dholmes at openjdk.org  Wed Apr  9 03:05:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Apr 2025 03:05:29 GMT
Subject: RFR: 8354088: [BACKOUT]  Run jtreg in the work dir
In-Reply-To: <0orWuc90j-dzUryymy0jlWkevGgQtFysUnrWURV2Y5c=.2310f8de-4ee6-4180-b1cb-932925bfaec3@github.com>
References: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
 <0orWuc90j-dzUryymy0jlWkevGgQtFysUnrWURV2Y5c=.2310f8de-4ee6-4180-b1cb-932925bfaec3@github.com>
Message-ID: <xwk6G0oJDpLAVxNOLr9tnEEj2NAtXEI99wmtH6LDLec=.21e5d502-6437-4ceb-9b2b-555b07ea1e3a@github.com>

On Wed, 9 Apr 2025 01:27:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> https://github.com/dholmes-ora/jdk/pull/new/8354088-backout
>> 
>> This reverts commit bd73a0641615d743663ef652bc1f27305af1517b.
>> 
>> It causes problems with paths to ProblemList files no longer being correct.
>> 
>> Re-tested tier3
>
> Marked as reviewed by darcy (Reviewer).

Thanks for the reviews @jddarcy  and @irisclark !

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

PR Comment: https://git.openjdk.org/jdk/pull/24531#issuecomment-2788162606

From dholmes at openjdk.org  Wed Apr  9 03:05:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Apr 2025 03:05:30 GMT
Subject: Integrated: 8354088: [BACKOUT]  Run jtreg in the work dir
In-Reply-To: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
References: <_nkkH4uYsPUBh5xk0uqs6MAgPqb0ReH21zE4NVRlHe4=.c35abf71-f589-4c53-8b92-5ff3d02c348b@github.com>
Message-ID: <sgt1a4kcRJQG3CD7XOgTrdqkLitVgd5jR5Pkbp5fPm0=.0b0bebee-6cfc-45c1-9774-720c5bc0477c@github.com>

On Wed, 9 Apr 2025 00:54:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> https://github.com/dholmes-ora/jdk/pull/new/8354088-backout
> 
> This reverts commit bd73a0641615d743663ef652bc1f27305af1517b.
> 
> It causes problems with paths to ProblemList files no longer being correct.
> 
> Re-tested tier3

This pull request has now been integrated.

Changeset: 2a0cf835
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a0cf8353ae0528a8417407d5719df0dadceadcf
Stats:     30 lines in 1 file changed: 13 ins; 16 del; 1 mod

8354088: [BACKOUT]  Run jtreg in the work dir

Reviewed-by: darcy, iris

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

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

From hannesw at openjdk.org  Wed Apr  9 04:15:20 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 9 Apr 2025 04:15:20 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Adjust color palette

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24417/files
  - new: https://git.openjdk.org/jdk/pull/24417/files/af50d173..05fc1a4a

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

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

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

From shade at openjdk.org  Wed Apr  9 08:13:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 08:13:33 GMT
Subject: RFR: 8187520: Add --disable-javac-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <d803lrfHgnaWZ59eSFsxAMmWisc0sqTNjxYeN_Los8c=.75a676fd-f9eb-4669-8783-bd378e5d02a8@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

Apologies for bikeshedding, but why `*-javac-*`, and not `disable-java-warnings-as-errors`? I think we want to cover other Java tools, like `javadoc` as well?

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

PR Review: https://git.openjdk.org/jdk/pull/24486#pullrequestreview-2752507795

From liach at openjdk.org  Wed Apr  9 09:06:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 09:06:44 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
Message-ID: <C3IEo67qZpfH5yyn83yQ08d3mQrkwa8ZL3uVhGGq808=.e6bf0f81-229f-48c4-bb56-224577b30aa6@github.com>

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Tier 1-3 tests passed, only unrelated failure fixed by 8354088.

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

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2788873619

From ihse at openjdk.org  Wed Apr  9 10:27:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:27:40 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <YEeZMcaEa1Z0yPX5Y71y2KsNn22MWooMXTvK1p5bZDM=.b8e03ab4-b817-4aec-a3dc-a4d24a4c02cb@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
 <YEeZMcaEa1Z0yPX5Y71y2KsNn22MWooMXTvK1p5bZDM=.b8e03ab4-b817-4aec-a3dc-a4d24a4c02cb@github.com>
Message-ID: <Hb0Iq34fQky7rjwk7CuFKrY0y5fqxXtzJfjc9tuRv6c=.67d936b0-8e58-4fa4-9d26-f629f0f511c0@github.com>

On Tue, 8 Apr 2025 19:38:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.
>
> make/Coverage.gmk line 42:
> 
>> 40: JCOV_TEMP := $(JCOV_SUPPORT_DIR)/temp
>> 41: 
>> 42: ifneq ($(JCOV_MODULES), )
> 
> Is this redundant conditional done on purpose?

You mean as in a foreach on an empty variable will yield nothing? Yes, I thought that made to code clearer, but if you think otherwise I can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2035070873

From ihse at openjdk.org  Wed Apr  9 10:29:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:29:55 GMT
Subject: RFR: 8187520: Add --disable-java-warnings-as-errors configure
 option [v2]
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <RQSrkjciP3y1A1JyI4iNYUa2Rfhs7crq-hJ7cW3AsIY=.6369d1b0-d128-4cc6-a84d-b6d33cbff330@github.com>

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

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

  Rename from "javac" to "java"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24486/files
  - new: https://git.openjdk.org/jdk/pull/24486/files/9185139a..9533f7ed

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

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

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

From ihse at openjdk.org  Wed Apr  9 10:29:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:29:55 GMT
Subject: RFR: 8187520: Add --disable-java-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <_Z3XbLpPp43IJ0cGnUyIkpmUp2xq8BOrhJrbNhvFN7U=.8378bcc4-6ccf-40f1-b23b-3d935e7c96be@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

There were no other reason than that was how it was formulated in the JBS issue. If you think "java" is better than "javac", we can do that as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24486#issuecomment-2789184179

From shade at openjdk.org  Wed Apr  9 10:29:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 10:29:55 GMT
Subject: RFR: 8187520: Add --disable-java-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <h0KYqWLUYhZ5AdInkEh4W8RDiVP1q2d-qMYgxwzlMQo=.44dd39d1-162f-43b3-a96e-a372913c556d@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

Yeah, I think "java" is better. Now the bug itself needs a rename :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24486#issuecomment-2789185484

From ihse at openjdk.org  Wed Apr  9 10:31:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:31:39 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <PWGxjU1jSJO-8yCWpIMzAjqku3_27s8Gd93rjztJlng=.fe1ff3c3-bea5-447e-9e3f-10930f0b95ec@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Wait, `LOW` is `-O2`? ?  I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. *sigh*

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789200299

From ihse at openjdk.org  Wed Apr  9 10:35:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:35:31 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
Message-ID: <TBZCGDlm96nX1vX6Xd_2ETU1QLdxSprE1bR81wsJqmg=.1e1f05df-cf54-48a5-ad0a-ddf5b41ea7ea@github.com>

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Build changes look trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753004950

From ihse at openjdk.org  Wed Apr  9 10:38:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:38:42 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
Message-ID: <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review v2

make/modules/jdk.jlink/Java.gmk line 28:

> 26: ################################################################################
> 27: 
> 28: COPY += upgrade_files_java.base

Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035088155

From shade at openjdk.org  Wed Apr  9 10:38:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 10:38:42 GMT
Subject: RFR: 8187520: Add --disable-java-warnings-as-errors configure
 option [v2]
In-Reply-To: <RQSrkjciP3y1A1JyI4iNYUa2Rfhs7crq-hJ7cW3AsIY=.6369d1b0-d128-4cc6-a84d-b6d33cbff330@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
 <RQSrkjciP3y1A1JyI4iNYUa2Rfhs7crq-hJ7cW3AsIY=.6369d1b0-d128-4cc6-a84d-b6d33cbff330@github.com>
Message-ID: <v_FSlI6RWF7G3YxlLTS7SFbJp0VobVr1li3_ZGC_rM4=.7317dc63-02de-462d-91b5-725b074ac1db@github.com>

On Wed, 9 Apr 2025 10:29:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
>> 
>> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename from "javac" to "java"

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24486#pullrequestreview-2753011841

From ihse at openjdk.org  Wed Apr  9 10:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:41:45 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
 <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
Message-ID: <HrxVRCaDXgj0eC4ee65oC4c4nnX8DaLarvwaO5wLekk=.d8e30dcd-6b95-4538-85a0-4470d0aed5d6@github.com>

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Build changes look trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24212#pullrequestreview-2753017837

From ihse at openjdk.org  Wed Apr  9 10:43:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:43:42 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <TjFNHws6_0PaVj_9JJzD5E-jiIJQcYe_l4lNSlgCF-8=.c5faa809-5fd4-42ef-9f2f-60525db4f310@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

Build change look trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23395#pullrequestreview-2753024152

From ihse at openjdk.org  Wed Apr  9 10:43:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:43:44 GMT
Subject: Integrated: 8187520: Add --disable-java-warnings-as-errors configure
 option
In-Reply-To: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
References: <jNb7ISUZCBQqbI4KcE-2BaQ0tTohIG5FQAyjs0cpL9E=.0fbcce86-1cdb-4323-8875-a5bb026da393@github.com>
Message-ID: <k55SVXRf-CcXT11k73p7na98jY2-iccqdMYavi1jYFM=.e16ed2e4-7477-4f13-bf42-c85ac93119fa@github.com>

On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Analogous with how native warnings can be treated as errors or not using the `--disable-warnings-as-errors` configure flag, this patch introduces a `--disable-javac-warnings-as-errors` flag.
> 
> The reason that this is not made part of `--disable-warnings-as-errors` is discussed in the JBS issue, but in short, native warnings can easily occur due to different build environment or compiler versions, while javac warnings are platform independent and should only depend on the source code we compile. That means that this option is basically only needed by developers to temporary silence javac while developing new code.

This pull request has now been integrated.

Changeset: 7aeaa3c2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7aeaa3c21c1420191fe8ff59e4cf99eae830754d
Stats:     29 lines in 5 files changed: 20 ins; 7 del; 2 mod

8187520: Add --disable-java-warnings-as-errors configure option

Reviewed-by: shade, erikj

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

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

From mbaesken at openjdk.org  Wed Apr  9 10:44:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Apr 2025 10:44:39 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

> Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_

Yes  see
https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L310

on gcc/clang  `C_O_FLAG_NORM="-O2"`  

and for LOW optimization level of a lib, we use the FLAG_NORM , see
https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L46

    else ifeq ($$($1_OPTIMIZATION), LOW)
      $1_OPT_CFLAGS := $(C_O_FLAG_NORM)
      $1_OPT_CXXFLAGS := $(CXX_O_FLAG_NORM)

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789230263

From sgehwolf at openjdk.org  Wed Apr  9 11:41:36 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 11:41:36 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
Message-ID: <SxBG3j4dx4P2j5q0-7eYyahFdua2Ctc14VcWQrSJHJg=.6cedeaca-bf90-4b54-a94b-b3803293e0b9@github.com>

On Wed, 9 Apr 2025 10:36:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review v2
>
> make/modules/jdk.jlink/Java.gmk line 28:
> 
>> 26: ################################################################################
>> 27: 
>> 28: COPY += upgrade_files_java.base
> 
> Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?

Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_<module>.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035181858

From ihse at openjdk.org  Wed Apr  9 11:45:30 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 11:45:30 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <SxBG3j4dx4P2j5q0-7eYyahFdua2Ctc14VcWQrSJHJg=.6cedeaca-bf90-4b54-a94b-b3803293e0b9@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
 <SxBG3j4dx4P2j5q0-7eYyahFdua2Ctc14VcWQrSJHJg=.6cedeaca-bf90-4b54-a94b-b3803293e0b9@github.com>
Message-ID: <lgAIxkVg5HCsCWJ9I39DpG_JA82vgjLFSObKG4PSjKA=.1dcfa977-2485-4018-9999-5dc14a9a9564@github.com>

On Wed, 9 Apr 2025 11:38:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> make/modules/jdk.jlink/Java.gmk line 28:
>> 
>>> 26: ################################################################################
>>> 27: 
>>> 28: COPY += upgrade_files_java.base
>> 
>> Any chance you can give this file a different name? It looks like it has extension `.base`. Maybe `upgrade_files_java.base.txt`, and then we can have a more general pattern of `*.txt`? Or maybe it should really be a properties file, to clearly indicate the nature of the file?
>
> Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_<module>.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?

Yeah, my comment was meant more like "maybe you should turn it into a proper properties file, by introducing a key name". But maybe that's just silly and overkill.

`.conf` sounds fine, I guess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035187744

From ihse at openjdk.org  Wed Apr  9 12:29:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:29:40 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <zkNm-R-KDCm8Hqsi3ghv5tVwifcgczCFiZqpxQrGOrM=.c3ab09df-b0c2-4059-811e-92df026c3661@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

O.M.G.

This is sooo messed up. I am thinking about making a special build where I set everything to -O3 and another where I set everything to -Os and just see what difference it makes in size and performance tests, and then suggest just going for one of them at the general rule (with exceptions for individual libraries, if needed).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789534753

From ihse at openjdk.org  Wed Apr  9 12:33:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:33:35 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <zrqZ2uHwdLGZ-8N_LY9G-wVV2NeFVRqIlzQDeQgI4h8=.8e124a7f-e919-486c-9c1d-2358d6a83bec@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

We also really must skip the dichotomy between `C_O_FLAG` and `OPTIMIZATION`, it just makes no sense whatsoever.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789545415

From ihse at openjdk.org  Wed Apr  9 12:36:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:36:37 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

I'd like to move to a world where we basically have just two optimization levels, "size" and "speed", and libraries do not in general have the level specified, so it falls back on a default, which could then be set by configure. For individual libraries we might need to override the default value, if we know that certain compilers make a mess of certain optimization levels, or if some libraries are especially performance sensitive. (Making hotspot `-Os` would certainly never make any sense, for example.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789552092

From sgehwolf at openjdk.org  Wed Apr  9 13:22:32 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 13:22:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <lgAIxkVg5HCsCWJ9I39DpG_JA82vgjLFSObKG4PSjKA=.1dcfa977-2485-4018-9999-5dc14a9a9564@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <14ZPPDXO-VOJwlTuN934jfJF1-_yGlfH8pEQyHQh9QA=.b80aa673-4cb9-410e-b489-039aa6506bcb@github.com>
 <SxBG3j4dx4P2j5q0-7eYyahFdua2Ctc14VcWQrSJHJg=.6cedeaca-bf90-4b54-a94b-b3803293e0b9@github.com>
 <lgAIxkVg5HCsCWJ9I39DpG_JA82vgjLFSObKG4PSjKA=.1dcfa977-2485-4018-9999-5dc14a9a9564@github.com>
Message-ID: <-WHxsRmElMyplPKGDTvavb-Bv0v-dJGqIYshTTgKvfY=.33c0a93e-a30d-4381-8167-5c9788a8a80d@github.com>

On Wed, 9 Apr 2025 11:42:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Sure. It's not really a properties file (which assumes `key=value`). How about `upgrade_files_<module>.conf`? Then the pattern could be `upgrade_files_*.conf`. Thoughts?
>
> Yeah, my comment was meant more like "maybe you should turn it into a proper properties file, by introducing a key name". But maybe that's just silly and overkill.
> 
> `.conf` sounds fine, I guess.

Thanks. Making this a properties file is overkill and feels like fitting a square peg into a round hole. I'll make those `*.conf` files then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2035358134

From erikj at openjdk.org  Wed Apr  9 14:09:42 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 9 Apr 2025 14:09:42 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <Hb0Iq34fQky7rjwk7CuFKrY0y5fqxXtzJfjc9tuRv6c=.67d936b0-8e58-4fa4-9d26-f629f0f511c0@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
 <YEeZMcaEa1Z0yPX5Y71y2KsNn22MWooMXTvK1p5bZDM=.b8e03ab4-b817-4aec-a3dc-a4d24a4c02cb@github.com>
 <Hb0Iq34fQky7rjwk7CuFKrY0y5fqxXtzJfjc9tuRv6c=.67d936b0-8e58-4fa4-9d26-f629f0f511c0@github.com>
Message-ID: <tmK-YcbpoNrOCj9qqrreeMULNkIdzNssn6ypL8XTXAk=.214281fa-fcdf-4135-9659-25bdcffc6930@github.com>

On Wed, 9 Apr 2025 10:24:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/Coverage.gmk line 42:
>> 
>>> 40: JCOV_TEMP := $(JCOV_SUPPORT_DIR)/temp
>>> 41: 
>>> 42: ifneq ($(JCOV_MODULES), )
>> 
>> Is this redundant conditional done on purpose?
>
> You mean as in a foreach on an empty variable will yield nothing? Yes, I thought that made to code clearer, but if you think otherwise I can remove it.

No, it's fine, I just wanted to know if it was intentional for code clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2035457864

From mbaesken at openjdk.org  Wed Apr  9 14:20:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Apr 2025 14:20:40 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
Message-ID: <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>

On Wed, 9 Apr 2025 12:33:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Making hotspot -Os would certainly never make any sense, for example

We even have this (jvm feature opt-size) 
https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L197
but it is not widely used afaik.
I think in the past it was used for certain small deployments (and a few very performance sensitive files , see the list from the link, still use 'speed optimization' ).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789899406

From jlahoda at openjdk.org  Wed Apr  9 14:32:43 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Apr 2025 14:32:43 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
 <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
Message-ID: <J37sNeOxA4WzyZQx-YK-osdi7MCCha0nVgpji1SGXGQ=.d93b159e-c4a3-4dcb-becc-90d4f5be3ad5@github.com>

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

I skimmed through the `CreateSymbols` changes, used `test/langtools/tools/javac/sym/PrintCTSymContent.java` to print ct.sym content before and after, and let the tool that generates the `.sym.txt` to run for JDK 24. All seems fine to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24212#pullrequestreview-2753708018

From liach at openjdk.org  Wed Apr  9 14:55:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:55:40 GMT
Subject: RFR: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API [v2]
In-Reply-To: <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
 <axlBPFG2jHBchcFdEQ8284mdRfFYL3Dofh_e0IR0luw=.d2a3dbcf-d489-4d88-845c-658ba4d39c33@github.com>
Message-ID: <dTMaRvT6CP3jvg1SKA6zxqEQbxSMPUMqrKz-mCUCtRY=.4ca33a52-73ad-497c-8bfa-8f0b47141e18@github.com>

On Tue, 8 Apr 2025 20:33:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
>> 
>> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
>> 
>> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Thanks Nizar, Jan, and Magnus for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24212#issuecomment-2790001750

From liach at openjdk.org  Wed Apr  9 14:55:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 14:55:41 GMT
Subject: Integrated: 8310310: Migrate CreateSymbols tool in make/langtools to
 Classfile API
In-Reply-To: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
References: <gIXH7RksPPd3f5IIEUj6I4QLr7vKO9fX0ux9J4_4xaU=.b95d01b8-a663-4651-b117-f17e537bff19@github.com>
Message-ID: <0TifGTZ6i79pWMlLNMk2NtrV0Zma57-jybekTj0f0QE=.91da1273-0927-4909-b1aa-facec1ece4ef@github.com>

On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrates the CreateSymbols tool to use the ClassFile API, away from com.sun.tools.classfile.
> 
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this is open to reviews.
> 
> Together with #24206, the old com.sun.tools.classfile can be removed from the JDK.

This pull request has now been integrated.

Changeset: 4dc9e589
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4dc9e58906772bf8ee444cb1618aa43f66593d79
Stats:     1057 lines in 5 files changed: 42 ins; 696 del; 319 mod

8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Reviewed-by: ihse, jlahoda

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

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

From liach at openjdk.org  Wed Apr  9 15:04:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 15:04:24 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
Message-ID: <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - 8352748: Remove com.sun.tools.classfile from the JDK
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - Other references to remove
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
 - FieldDescription.constantValue uses Integer for byte and short
 - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

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

Changes: https://git.openjdk.org/jdk/pull/24528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24528&range=01
  Stats: 10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24528/head:pull/24528

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

From ihse at openjdk.org  Wed Apr  9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:

> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)

This does not seem to have been a correct conversion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242

From jlahoda at openjdk.org  Wed Apr  9 15:17:33 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Apr 2025 15:17:33 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
 <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
Message-ID: <8fGvLxgB44Zln3uK7Htt3LWMvCkiTYqpsGKNTDDJ7Do=.19e52043-d624-44b3-a901-85869fe9498c@github.com>

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Looks good to me. I won't increase the reviewer count, but please wait a few days to give others chance to comment if they choose to.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753858690

From ihse at openjdk.org  Wed Apr  9 15:23:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:23:17 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII
Message-ID: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>

I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.

In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).

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

Commit messages:
 - 8354213: Restore pointless unicode characters to ASCII

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

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

From ihse at openjdk.org  Wed Apr  9 15:39:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:39:16 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v2]
In-Reply-To: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
Message-ID: <pXjutqKyYWe5R75K0QUwnYq3fiEyHotrYBRTNebuTZk=.9ce77a94-ffdb-4db1-8f91-b4af8f2ff98b@github.com>

> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
> 
> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).

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

  Also fix pointless unicode characters for tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24552/files
  - new: https://git.openjdk.org/jdk/pull/24552/files/4197daa9..284b278d

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

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

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

From vromero at openjdk.org  Wed Apr  9 15:43:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Apr 2025 15:43:42 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
 <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
Message-ID: <EIicDV-4_Sprb4Sxw4jzuto6nf6FkRwQr8kKuMO8QH0=.bff186f2-62ed-49fe-8ecc-9158a6843782@github.com>

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24528#pullrequestreview-2753941212

From rriggs at openjdk.org  Wed Apr  9 15:48:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Apr 2025 15:48:40 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <nAvCE7YQqNM6CI5uxiapAL2zBx2NUWNKb2Tj5caF0UQ=.2ea01d61-87ca-49f6-86f9-ca3c0b2529bf@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

For methods that have "@PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS, reflective=true)" annotations
the first (summary) line in the list of methods is "Preview." without any decoration. Is that intended?

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

PR Comment: https://git.openjdk.org/jdk/pull/23395#issuecomment-2790167667

From ihse at openjdk.org  Wed Apr  9 15:53:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:53:51 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v3]
In-Reply-To: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
Message-ID: <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>

> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
> 
> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).

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

  Oops.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24552/files
  - new: https://git.openjdk.org/jdk/pull/24552/files/284b278d..56808d8c

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

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

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

From sgehwolf at openjdk.org  Wed Apr  9 16:10:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 16:10:20 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
Message-ID: <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

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

  Use *.conf for upgrade files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24388/files
  - new: https://git.openjdk.org/jdk/pull/24388/files/89d3886d..4434c78e

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

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

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

From naoto at openjdk.org  Wed Apr  9 17:24:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 9 Apr 2025 17:24:43 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v3]
In-Reply-To: <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
 <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
Message-ID: <Gbld5AFlpFUKD85FqZJ14M7UEm9LdKHNSaq7bwJqMWs=.08fb2aba-f052-441d-8b07-294391b07cd0@github.com>

On Wed, 9 Apr 2025 15:53:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
>> 
>> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Oops.

Looks good to me. I was just expecting the usual suspects, such as, apostrophe/hyphen-minus variations in comments, but never expected zero-width space, or Cyrillic "C" in place for ascii "C" in the code!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24552#pullrequestreview-2754211738

From hannesw at openjdk.org  Wed Apr  9 17:26:50 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 9 Apr 2025 17:26:50 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <nAvCE7YQqNM6CI5uxiapAL2zBx2NUWNKb2Tj5caF0UQ=.2ea01d61-87ca-49f6-86f9-ca3c0b2529bf@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <nAvCE7YQqNM6CI5uxiapAL2zBx2NUWNKb2Tj5caF0UQ=.2ea01d61-87ca-49f6-86f9-ca3c0b2529bf@github.com>
Message-ID: <YW0IL558UKSLrFeaImGSnKT3OKqXnwoWAqLdyBAs4rs=.f3cf816e-c84b-4976-a1cb-713d02111343@github.com>

On Wed, 9 Apr 2025 15:45:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> For methods that have "@PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS, reflective=true)" annotations the first (summary) line in the list of methods is "Preview." without any decoration. Is that intended?

Yes, that's intended. Not very pretty, but hard to miss.

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

PR Comment: https://git.openjdk.org/jdk/pull/23395#issuecomment-2790448425

From erikj at openjdk.org  Wed Apr  9 17:57:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 9 Apr 2025 17:57:43 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v3]
In-Reply-To: <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
 <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
Message-ID: <fxrJ6z6-y6NOtnwgYnVJAVExbMJrTjwlVbzRTqnbzwM=.275cc495-38bd-4f1f-8d1c-429f27432ffb@github.com>

On Wed, 9 Apr 2025 15:53:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
>> 
>> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Oops.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24552#pullrequestreview-2754290885

From rriggs at openjdk.org  Wed Apr  9 17:58:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Apr 2025 17:58:44 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <TCLwUwdqBJEi0OYVkjbOFvxZOoWeKQgeX_qK3mqXQo4=.69fa54ef-0f76-4f20-9e40-a03d25d2dd14@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

Yuck.  It would, IMHO, look better if it was a BOLD prefix of the first sentence. i.e.

**Preview Feature:** Checks that the specified object reference is an identity object.

$.02

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

PR Comment: https://git.openjdk.org/jdk/pull/23395#issuecomment-2790517937

From iris at openjdk.org  Wed Apr  9 18:15:34 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 9 Apr 2025 18:15:34 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v3]
In-Reply-To: <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
 <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
Message-ID: <5_CH1LUp-76OBgk1X2EX8515DRsyt9Z2kbnSoR29RCA=.b9e48d3d-bf08-4ac1-99fe-3e86d57e1903@github.com>

On Wed, 9 Apr 2025 15:53:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
>> 
>> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Oops.

Thanks for fixing!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24552#pullrequestreview-2754330944

From ihse at openjdk.org  Wed Apr  9 20:16:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 20:16:35 GMT
Subject: RFR: 8354213: Restore pointless unicode characters to ASCII [v3]
In-Reply-To: <Gbld5AFlpFUKD85FqZJ14M7UEm9LdKHNSaq7bwJqMWs=.08fb2aba-f052-441d-8b07-294391b07cd0@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
 <oIViiET4LB0ET0KF7cV01qCRhjy19BfJGYUg2yC1T4c=.907f8d96-7599-4ebc-be31-45f2f7f29d06@github.com>
 <Gbld5AFlpFUKD85FqZJ14M7UEm9LdKHNSaq7bwJqMWs=.08fb2aba-f052-441d-8b07-294391b07cd0@github.com>
Message-ID: <YNQbrFsMp_PMRxz6rb6s9wOquRuH1lvm8xoL7NubnPc=.b95fddd7-a311-4079-aa36-fe71fc599571@github.com>

On Wed, 9 Apr 2025 17:22:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> never expected zero-width space, or Cyrillic "C" in place for ascii "C" in the code!

Yes, these got some extra bonus points. :-) I'm also curious what the almost-comma is supposed to be, but never bothered to look it up. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24552#issuecomment-2790892094

From ihse at openjdk.org  Wed Apr  9 20:16:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 20:16:36 GMT
Subject: Integrated: 8354213: Restore pointless unicode characters to ASCII
In-Reply-To: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
References: <SyHZwOJqRUZ4x4o2nLYoBmhmLvE2VmRzwOaRlpCiVjM=.60ab9030-a46c-429e-ab62-d19876125944@github.com>
Message-ID: <JqRSyhsyQQpXZWr1_w_IUBDQoR266jUwUmd8kNHeRek=.e2d5e9c3-59cc-492e-81c5-7a09b7d12ab2@github.com>

On Wed, 9 Apr 2025 15:17:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I believe the source code of the JDK should be in US-ASCII if possible, and only employ extended characters if that is strictly necessary for the code to work.
> 
> In my attempt to figure out which non-ascii files are another encoding than utf-8 (see [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)), I discovered a handful of files that use unicode characters for no good reason, when normal ASCII characters could have been used (and have been used everywhere else in the code base in similar contexts).

This pull request has now been integrated.

Changeset: 4a242e3a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a242e3a65f13c41c699d42b100ba2b252d7faaa
Stats:     45 lines in 22 files changed: 0 ins; 0 del; 45 mod

8354213: Restore pointless unicode characters to ASCII

Reviewed-by: naoto, erikj, iris

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

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

From ihse at openjdk.org  Wed Apr  9 20:26:33 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 20:26:33 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
Message-ID: <qu1oKbyxtCi5ymmXeh6lan4eT-K0r7xkMQ2m6HFm-mw=.3e23a39a-73cd-44e3-ba51-a16d8172ac1c@github.com>

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2754729383

From cjplummer at openjdk.org  Wed Apr  9 20:28:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:28:33 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
 <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
Message-ID: <A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>

On Wed, 9 Apr 2025 14:17:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Making hotspot `-Os` would certainly never make any sense, for example.)

When the minimalVM was first created, there was a quite of bit of benchmarking done to decide which hotspot files to build with -Os and which to build with -O3. I'm not sure if this split survived the new build system, but for those wanting a truly minimal footprint with reasonable performance sacrifices, it still makes sense to build all or most of hotspot with -Os.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2790923666

From ihse at openjdk.org  Wed Apr  9 20:29:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 20:29:45 GMT
Subject: RFR: 8345874: Run make doctor automatically on failed CI builds
 [v2]
In-Reply-To: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>
References: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>
Message-ID: <aP_O9sjC7Z4SKP926eonLrqLRHc49tzkwhKBvhAqdrs=.ac8da7ea-e2d2-41c8-b9de-c3923ab1e518@github.com>

> If there is something wrong with the build, the user can run "make doctor". That is hard to do in a CI setting. Instead, if the build environment is detected to be a CI, we should run the doctor automatically in case of a failed build.

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 two commits:

 - Merge branch 'master' into make-doctor-on-ci
 - 8345874: Run make doctor automatically on failed CI builds

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

Changes: https://git.openjdk.org/jdk/pull/24485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24485&range=01
  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24485/head:pull/24485

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

From cjplummer at openjdk.org  Wed Apr  9 20:37:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:37:33 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
Message-ID: <XkGbUGRdFEN2yW2Gl5KVahM0oWX00JkyVuElZ6OvIzs=.f3e3aa53-b7b4-4a1e-9349-6a8012824ffe@github.com>

On Wed, 9 Apr 2025 10:41:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_

-Os is the same as -O2 minus some optimizations that increase footprint.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

-O3 mostly adds more serious footprint increasing optimizations like loop unrolling. I've seen a number of warnings that suggest in some cases the larger code can reduce performance, so you may be best off with -O2 or -Os for best performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2790938638

From mikael at openjdk.org  Wed Apr  9 20:48:09 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 9 Apr 2025 20:48:09 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
Message-ID: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>

[JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.

Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

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

Commit messages:
 - 8354230: Wrong boot jdk for alpine-linux-x64 in GHA

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

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

From jlu at openjdk.org  Wed Apr  9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>

On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Convert the merged master changes to UTF-8
>>  - Merge master and fix conflicts
>>  - Close streams when finished loading into props
>>  - Adjust CF test to read in with UTF-8 to fix failing test
>>  - Reconvert CS.properties to UTF-8
>>  - Revert all changes to CurrencySymbols.properties
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
> 
> This does not seem to have been a correct conversion.

Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)

Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417

From erikj at openjdk.org  Wed Apr  9 21:46:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 9 Apr 2025 21:46:39 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <YfDWMuib8Q7i7yGkTgqUOFlShnRnyPdiJU60J3EeH0s=.dccec92a-c6f7-4ee8-add0-b9b45862a7e7@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24557#pullrequestreview-2754875369

From iris at openjdk.org  Wed Apr  9 22:54:24 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 9 Apr 2025 22:54:24 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <uq7ObfzWVSFsfH2g42VJFr8UQfbb2xdn9Ikm6dJisSw=.d729fddd-851c-4e03-8a3b-07d981989fde@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24557#pullrequestreview-2754957393

From liach at openjdk.org  Wed Apr  9 22:59:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 22:59:27 GMT
Subject: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]
In-Reply-To: <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
 <bv7wlALSlQQXyogey3Wta3SS5DEYMlt251uGZqvIEGI=.fef94ff5-6a3d-46fe-b5e3-367c272f5e0e@github.com>
Message-ID: <aXTPeF4vgWd2Atobks5pelR6uTjAFhyo-DjPc6_C8VQ=.4b46b2d7-e373-4a4e-a8ae-d723acf38d4b@github.com>

On Wed, 9 Apr 2025 15:04:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
>> 
>> Testing: built locally, running tier 1-3 tests
>> 
>> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - 8352748: Remove com.sun.tools.classfile from the JDK
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/remove-old-classfile
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - Other references to remove
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/migrate-create-symbols
>  - FieldDescription.constantValue uses Integer for byte and short
>  - 8310310: Migrate CreateSymbols tool in make/langtools to Classfile API

Tier 1-3 tests all pass. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24528#issuecomment-2791008239

From liach at openjdk.org  Wed Apr  9 23:02:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Apr 2025 23:02:34 GMT
Subject: Integrated: 8352748: Remove com.sun.tools.classfile from the JDK
In-Reply-To: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
References: <YQwv0DDkmQ4jMjE31coxgwm94gKw_Fk05bj2109Shyw=.733804ea-3b09-4311-8c40-5ade44cfc08f@github.com>
Message-ID: <rnPqpOvH2a3q5Dgo4kGOLokOB3JTREqY91tTCwAVcgM=.19f837d9-47a0-4be8-adab-0411e6c55184@github.com>

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> With all dependencies of com.sun.tools.classfile in the JDK converted to the ClassFile API, we can remove this legacy library for release 25 like how we removed ASM.
> 
> Testing: built locally, running tier 1-3 tests
> 
> Don't know why, but GitHub is redundantly displaying changes that are already in #24212.

This pull request has now been integrated.

Changeset: 5c438c5e
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c438c5e6b636a7992cbd737de0735070e480061
Stats:     10015 lines in 70 files changed: 0 ins; 10009 del; 6 mod

8352748: Remove com.sun.tools.classfile from the JDK

Reviewed-by: ihse, jlahoda, vromero

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

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

From mbaesken at openjdk.org  Thu Apr 10 07:15:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Apr 2025 07:15:30 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
 <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
 <A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>
Message-ID: <oQOhk3uyl29N9qzgwZW2nsleDpLJ6HcXF-24L0mq0Ho=.802015bd-37ed-4335-a0a4-2e6a81632b01@github.com>

On Wed, 9 Apr 2025 20:26:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Making hotspot `-Os` would certainly never make any sense, for example.)
> 
> When the minimalVM was first created, there was a quite of bit of benchmarking done to decide which hotspot files to build with -Os and which to build with -O3. I'm not sure if this split survived the new build system, but for those wanting a truly minimal footprint with reasonable performance sacrifices, it still makes sense to build all or most of hotspot with -Os.

The list  to decide which hotspot files to build with -Os and which to build with -O3 (OPT_SPEED_SRC ) is still present , see https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L197 . Probably the list is a bit outdated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2791779866

From djelinski at openjdk.org  Thu Apr 10 07:20:27 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 10 Apr 2025 07:20:27 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <K8m571h_WTl7FunVVl6XKcN8y02mfltOdmhJYDPElCE=.8e650b0b-37c9-48f4-995b-f6e443f84989@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24557#pullrequestreview-2755600423

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
Message-ID: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>

On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>> 
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>> 
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
> 
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
Message-ID: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>

On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>> 
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723

From eirbjo at openjdk.org  Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>

On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

Some observations: 

1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?

2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.

3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`

4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:


byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
``` 

Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319

From mbaesken at openjdk.org  Thu Apr 10 08:24:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Apr 2025 08:24:04 GMT
Subject: RFR: 8354254: Remove the linux ppc64 -minsert-sched-nops=regroup_exact
 compile flag
Message-ID: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>

On linux ppc64 / gcc , we build with the compile flag -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it was still useful for old Power6 machines.

See https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS_002f6000-and-PowerPC-Options.html
-minsert-sched-nops=scheme : This option controls which NOP insertion scheme is used during the second scheduling pass. The argument scheme takes one of the following values:
?regroup_exact? : Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.

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

Commit messages:
 - JDK-8354254

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

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

From ihse at openjdk.org  Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
 <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: <qG3Fpev16BBWYvs2zSE5CeqmTcfRF4h_l-PAM3PVHns=.4a1e25de-c3e2-4876-a8e5-c3f32cfef4c1@github.com>

On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations: 
> 
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
> 
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
> 
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
> 
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
> 
> 
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ``` 
> 
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?

Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765

From ihse at openjdk.org  Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <yO1q1NVjOInbzcWCkJra3sYGkfv3OBhg__dKO0w--s0=.d7a4b185-6ed1-4ae6-bdfe-01b3204da46a@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.

As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157

From sgehwolf at openjdk.org  Thu Apr 10 08:45:32 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 08:45:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: <BRlwsTVZQloBa-RoKMyiCNCzRtqHLHdgtQgO3t6qX_8=.38449b2d-3605-415e-9b49-bd2ba9520bea@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <9QVEBGTFqMGaocyisN_zUY9mqQtC3mnJoazB0TH0yqU=.6035d751-84b5-4aa3-baf5-e2d02f692565@github.com>
 <_mC3xJvbf0K_Bb4ywZIMUzDFiUzs70vIZz48z43R5-k=.3c8e049b-a869-4cfa-9623-c30ffea6c549@github.com>
 <BRlwsTVZQloBa-RoKMyiCNCzRtqHLHdgtQgO3t6qX_8=.38449b2d-3605-415e-9b49-bd2ba9520bea@github.com>
Message-ID: <u-dbaZ-qSbtznS6ov_CXefjwhn5I5hB61souMdnAOuA=.ecf348b1-7bd6-45ad-9cfa-2364b22bfbd4@github.com>

On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Part of me is concerned that the hidden option is a bit of an attractive nuisance. What would you think about just having a fixed list in a properties file in the repo, thus a resource in the jlink module. This would avoid the list in JRTArchive too. It wouldn't rule out introducing something more in the future.
>> 
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
>> 
>>> Right now the only examples we have are in java.base. In time it might be that some other modules might need something.
>> 
>> Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from).
>>  
>>> I've like to know more about cacerts. Are the distros swapping this to a link after the run-time image is created or is it that the sym link is there from the startup and the hashing has followed the link?
>> 
>> Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced  with a symlink after the JDK has been built.
>> 
>> Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build.
>> 
>> The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory.
>
>> I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well.
> 
> Yes, I think keep simple. We always want to allow tzdb.dat be upgraded by the TZ updater tool. I think treating cacerts the same way is okay. As you note, it has to be kept up to date too. I was thinking keytool import and wasn't sure if the Linux distros configure with `-with-cacerts-file` or did something else. Thanks for the clarification on this point.
> 
> Starting with a simple list of two files won't preclude us from re-visiting it again in the future.

@AlanBateman Any more thoughts on this? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2792010497

From eirbjo at openjdk.org  Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

FWIW, I checked out the revision of the commit previous to this change and found the following:


% git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
  ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
  Unicode text, UTF-8 text, with very long lines (322)


Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164

From alanb at openjdk.org  Thu Apr 10 09:06:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 09:06:32 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
Message-ID: <S_vSLeQD66nP1RRxhZhiVCGLoeMNWRnzxPvFEegpNFc=.20be3f06-85d5-4939-9e0e-e6f804236a18@github.com>

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14308729271))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2755918801

From alanb at openjdk.org  Thu Apr 10 09:06:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 09:06:33 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <tdUr_l_21OWfwoPvUZh9E0iu8O95Tqchwyb1PaMYMR8=.a5ed7608-cf36-487e-ada1-48f6b45e305c@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <EJ9hPfADEdmaWV4u6UZ8q9S6Szo9Uj7hEa8FHXs_oPw=.dbcb8ad5-3536-4707-94d1-46e1aa74ee8f@github.com>
 <tdUr_l_21OWfwoPvUZh9E0iu8O95Tqchwyb1PaMYMR8=.a5ed7608-cf36-487e-ada1-48f6b45e305c@github.com>
Message-ID: <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>

On Tue, 8 Apr 2025 13:31:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 71:
>> 
>>> 69:     private static InputStream getDiffInputStream(String module) throws IOException {
>>> 70:         String resourceName = String.format(DIFF_PATTERN, module);
>>> 71:         return JDK_JLINK_MOD.getResourceAsStream(resourceName);
>> 
>> FYI you can use LinkableRuntimeImage.class.getResourceAsStream here as the resource is in the current module.
>
> It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.

Without reproducing, I can't immediately say why Class.getResourceAsStream would fail here. This is a good API for locating resources in the caller's module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2036873997

From sgehwolf at openjdk.org  Thu Apr 10 09:15:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 09:15:42 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
 <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
Message-ID: <5y_3A2YWz__mEiqO4riiVGAh5w53JG_h0FS8Gi7o9-w=.b2844f4a-bdff-4081-880c-c95bf6a6ca3c@github.com>

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> Just a few fly-by findings, no full review.
> 
> I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

@RealCLanger Are you OK with the latest patch (as far as your comments are concerned)?

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2792092525

From sgehwolf at openjdk.org  Thu Apr 10 09:15:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 09:15:43 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v4]
In-Reply-To: <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <bpcUv2UbQNMtkJ6mS_m-go9Ng1ZcsaHW5QgsTGZl-Z4=.a7d9ceaf-8f2c-43c1-b113-e645ac934c37@github.com>
 <EJ9hPfADEdmaWV4u6UZ8q9S6Szo9Uj7hEa8FHXs_oPw=.dbcb8ad5-3536-4707-94d1-46e1aa74ee8f@github.com>
 <tdUr_l_21OWfwoPvUZh9E0iu8O95Tqchwyb1PaMYMR8=.a5ed7608-cf36-487e-ada1-48f6b45e305c@github.com>
 <4gu4eWXHBckNDOf135DTWPDAP2pG5cuOl5dniQleJJk=.860242cd-b74a-4b4c-81e0-df05027d77da@github.com>
Message-ID: <7IgtqWd24RIfYfO6D2tFKRxQ8BbkELzhReGh9VXG_tQ=.8a405f59-757e-43b9-9dd5-9369451598e5@github.com>

On Thu, 10 Apr 2025 09:03:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's very odd, but when I attempt this then the resource is not found. It seems to fail on the module name verification. For example: `jlink --help | tail -n2` shows as `disabled` for an enabled linkable runtime image.
>
> Without reproducing, I can't immediately say why Class.getResourceAsStream would fail here. This is a good API for locating resources in the caller's module.

I'll try to find a reproducer outside this PR and will let you know if I find anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24388#discussion_r2036887632

From sgehwolf at openjdk.org  Thu Apr 10 09:25:35 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Apr 2025 09:25:35 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <VvktBSgAVweQfwZYtDmAC43j4w0G7rqYFnKUhdassA4=.ba6e28e5-257f-4a22-82bf-c03e21e9e65f@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

Failure seen in https://github.com/mhaessig/jdk/actions/runs/14376762241/job/40310956644#step:6:478


 configure:85518: Output from java -version was: /__w/jdk/jdk/build/.configure-support/generated-configure.sh: line 85490: /__w/jdk/jdk/bootjdk/jdk/bin/java: cannot execute binary file: Exec format error
configure:85611: error: The path given by --with-boot-jdk does not contain a valid Boot JDK


... is gone in this PR. Looks fine.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24557#pullrequestreview-2755979818

From hannesw at openjdk.org  Thu Apr 10 09:29:32 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 10 Apr 2025 09:29:32 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <TCLwUwdqBJEi0OYVkjbOFvxZOoWeKQgeX_qK3mqXQo4=.69fa54ef-0f76-4f20-9e40-a03d25d2dd14@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <TCLwUwdqBJEi0OYVkjbOFvxZOoWeKQgeX_qK3mqXQo4=.69fa54ef-0f76-4f20-9e40-a03d25d2dd14@github.com>
Message-ID: <EL-SUUTL899HNA112butMwyGPUKqowb0Rgimw_nQw4o=.3ac59a79-b396-4a49-bb66-4321f3f98546@github.com>

On Wed, 9 Apr 2025 17:55:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It would, IMHO, look better if it was a BOLD prefix of the first sentence. 

I partly agree, but I also think the stamp-like nature serves a purpose. Note that deprecated members and restricted methods use the same format, sometimes adding a full sentence:

https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Runtime.html#method-summary
https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/applet/Applet.html#method-summary 

So I think it could be improved, but should be part of an effort to improve marking of "special" elements in general.

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

PR Comment: https://git.openjdk.org/jdk/pull/23395#issuecomment-2792128552

From ihse at openjdk.org  Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <GlAmyjF3ZmTQHUhkTXRmmrijCWM_4JoredRJOuyVyIc=.775fbc8d-80da-4b0b-b2e1-e5b7e75b3d52@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Thanks for checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460

From ihse at openjdk.org  Thu Apr 10 10:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:18:13 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <i-DS7NdhCKyhiRavUvimxeFqQ5MM6q9kshasPnqG1DQ=.bc74c153-8710-4970-803b-4767db7c18ac@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 497:

> 495: /*
> 496:   The algorithm below is based on Intel publication:
> 497:   "Fast SHA-256 Implementations on Intel(R) Architecture Processors" by Jim Guilford, Kirk Yap and Vinodh Gopal.

Note: There is of course a unicode `?` symbol, which is what it was originally before it was botched here, but I found no reason to keep this, and in the spirit of JDK-8354213, I thought it better to use pure ASCII here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037012318

From ihse at openjdk.org  Thu Apr 10 10:18:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 10:18:13 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
Message-ID: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>

I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 

BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.

Methodology used: 

I have run four different tools for using different heuristics for determining the encoding of a file:
* chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
* uchardet (a modern version by freedesktop, used by e.g. Firefox)
* enca (targeted towards obscure code pages)
* libmagic / `file  --mime-encoding`

They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
* `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`

>From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
* All files where at least one tool claimed it to be UTF-8
* All files where at least one tool claimed it to be *not* UTF-8

For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.

For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling extensions (most of these are in tests). The BOM files were only pointed out by chardetect; I did run an additional search for UTF-8 BOM markers over the code base to make sure I did not miss any others (since chardetect apart from this did a not-so-perfect job).

The files included in this PR are what I actually found that had encoding errors or issues.

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

Commit messages:
 - Remove UTF-8 BOM (byte-order mark) which is discouraged by the Unicode Consortium
 - Fix incorrect encoding

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

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

From rgiulietti at openjdk.org  Thu Apr 10 11:49:30 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 11:49:30 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <i-DS7NdhCKyhiRavUvimxeFqQ5MM6q9kshasPnqG1DQ=.bc74c153-8710-4970-803b-4767db7c18ac@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <i-DS7NdhCKyhiRavUvimxeFqQ5MM6q9kshasPnqG1DQ=.bc74c153-8710-4970-803b-4767db7c18ac@github.com>
Message-ID: <r9_dDyK75porkACjAcbL9ofGo3yrxqloCmN8eTGtL0k=.7d458844-16fd-4a36-ba01-41bdbfc6b519@github.com>

On Thu, 10 Apr 2025 10:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 497:
> 
>> 495: /*
>> 496:   The algorithm below is based on Intel publication:
>> 497:   "Fast SHA-256 Implementations on Intel(R) Architecture Processors" by Jim Guilford, Kirk Yap and Vinodh Gopal.
> 
> Note: There is of course a unicode `?` symbol, which is what it was originally before it was botched here, but I found no reason to keep this, and in the spirit of JDK-8354213, I thought it better to use pure ASCII here.

I guess the difference at L.1 in the various files is just the BOM?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037161789

From galder at openjdk.org  Thu Apr 10 12:08:57 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 10 Apr 2025 12:08:57 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH benchmarks
Message-ID: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>

Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.

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

Commit messages:
 - 8354257: xctracenorm profiler not working with JDK JMH benchmarks

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

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

From hannesw at openjdk.org  Thu Apr 10 13:05:36 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 10 Apr 2025 13:05:36 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <gu-RiVF5H71VJIsrw1cXMtXCHm7hr7oFgRd8PUN2IJM=.170667e8-08dc-4742-95c8-50d2391da4c1@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

Here's a selection of code fragments from the sample docs using syntax highlighting:

 - [Thread example](https://cr.openjdk.org/~hannesw/8348282/api.00/java.base/java/lang/Thread.html#snippet-java.lang.Thread1)
 - [Doclet example](https://cr.openjdk.org/~hannesw/8348282/api.00/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#example-heading)
 - [PropertyResourceBundle](https://cr.openjdk.org/~hannesw/8348282/api.00/java.base/java/util/PropertyResourceBundle.html#snippet-java.util.PropertyResourceBundle1)
- [ListResourceBundle](https://cr.openjdk.org/~hannesw/8348282/api.00/java.base/java/util/ListResourceBundle.html#snippet-java.util.ListResourceBundle1)
- [ClassFile example](https://cr.openjdk.org/~hannesw/8348282/api.00/java.base/java/lang/classfile/attribute/package-summary.html#snippet-java.lang.classfile.attribute1)
- [MethodHandles example](https://cr.openjdk.org/~hannesw/8348282/api.00/java.base/java/lang/invoke/MethodHandles.html#snippet-collectArguments(java.lang.invoke.MethodHandle,int,java.lang.invoke.MethodHandle)1)

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

PR Comment: https://git.openjdk.org/jdk/pull/24417#issuecomment-2792716273

From ihse at openjdk.org  Thu Apr 10 13:17:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 13:17:24 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <r9_dDyK75porkACjAcbL9ofGo3yrxqloCmN8eTGtL0k=.7d458844-16fd-4a36-ba01-41bdbfc6b519@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <i-DS7NdhCKyhiRavUvimxeFqQ5MM6q9kshasPnqG1DQ=.bc74c153-8710-4970-803b-4767db7c18ac@github.com>
 <r9_dDyK75porkACjAcbL9ofGo3yrxqloCmN8eTGtL0k=.7d458844-16fd-4a36-ba01-41bdbfc6b519@github.com>
Message-ID: <VoS2h6do98w3WnQOc5-NF4NVUmoa33Ip0-VdKJz1PRo=.5eb1d327-e0e2-4edf-bb98-269616e9be4f@github.com>

On Thu, 10 Apr 2025 11:46:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> I guess the difference at L.1 in the various files is just the BOM?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037357899

From rgiulietti at openjdk.org  Thu Apr 10 13:56:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 13:56:42 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <ZcN0G7Cq3aK0CNq8H68Veeyv5HD0faIuYgWjT9i_nPs=.f526890f-80a1-476d-9cc7-d450eb2a8a8f@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

I only checked these 13 files to be UTF-8 encoded and without BOM.

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2756936848

From liach at openjdk.org  Thu Apr 10 15:58:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 15:58:30 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <CoQ47v9tlIe9_ky02oOav5xSP1BCV93i5qiqO7x1q6c=.48f74b42-8afc-45ff-97a9-092a81fb5ec9@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

The code here and the usage example look good. We might integrate once Roger thinks the format looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23395#pullrequestreview-2757371812

From erikj at openjdk.org  Thu Apr 10 16:51:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 10 Apr 2025 16:51:36 GMT
Subject: RFR: 8354254: Remove the linux ppc64
 -minsert-sched-nops=regroup_exact compile flag
In-Reply-To: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
References: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
Message-ID: <8snOHpUjWqM1VGjgp9VA_hrcDE_-1VQPV0dcWUxZOYs=.0a522e6c-141e-41e1-97d8-d465721ad800@github.com>

On Thu, 10 Apr 2025 08:19:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On linux ppc64 / gcc , we build with the compile flag -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it was still useful for old Power6 machines.
> 
> See https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS_002f6000-and-PowerPC-Options.html
> -minsert-sched-nops=scheme : This option controls which NOP insertion scheme is used during the second scheduling pass. The argument scheme takes one of the following values:
> ?regroup_exact? : Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24564#pullrequestreview-2757576450

From naoto at openjdk.org  Thu Apr 10 17:12:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Apr 2025 17:12:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <DbpgtmWS1C9lLsRld9V1jjYvbjPycU0AkcBNF13pRhs=.d6e7773d-2278-4159-8aac-5f1ebe668404@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/java.desktop/share/legal/lcms.md line 72:

> 70: Mateusz Jurczyk (Google)
> 71: Paul Miller
> 72: S?bastien L?on

I cannot comment on capitalization here, but if we wanted to lowercase them, should they be e-grave instead of e-acute?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037895884

From erikj at openjdk.org  Thu Apr 10 17:13:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 10 Apr 2025 17:13:36 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
Message-ID: <xE28SZmLe41wZss7P9g4pb_-vfBM77EbIX13MxccNow=.315e6d35-dd38-41c4-b7c8-501a0c98006f@github.com>

On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.

The jmh-core jar file published in Maven central (https://repo.maven.apache.org/maven2/org/openjdk/jmh/jmh-core/1.37/jmh-core-1.37.jar), which is the one referenced from the devkit generator script, does not contain this `default.instruments.template.xml` file. The `rm` command seems to be aimed at `checkstyle.xml` and `findbugs.xml`, both of which I would assume to be irrelevant, but should also be benign, but I can't help but wonder why those files are included in the JMH distribution. In what kind of build configuration do you get `default.instruments.template.xml` bundled?

Unfortunately, the original author of the JDK build logic for micro benchmarks isn't available atm. I don't know enough about JMH to say if this is a reasonable change. Maybe @shipilev can fill in with some knowledge?

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

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2794585574

From rgiulietti at openjdk.org  Thu Apr 10 17:26:30 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Apr 2025 17:26:30 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <DbpgtmWS1C9lLsRld9V1jjYvbjPycU0AkcBNF13pRhs=.d6e7773d-2278-4159-8aac-5f1ebe668404@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <DbpgtmWS1C9lLsRld9V1jjYvbjPycU0AkcBNF13pRhs=.d6e7773d-2278-4159-8aac-5f1ebe668404@github.com>
Message-ID: <PMuiNu8QISDQCixlTbe8T-MKLiYTln_pnbZnVAu40rA=.54d48791-965f-4c43-af22-0f9fd347aeac@github.com>

On Thu, 10 Apr 2025 17:09:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/java.desktop/share/legal/lcms.md line 72:
> 
>> 70: Mateusz Jurczyk (Google)
>> 71: Paul Miller
>> 72: S?bastien L?on
> 
> I cannot comment on capitalization here, but if we wanted to lowercase them, should they be e-grave instead of e-acute?

If this is a French name, it's e acute: ?.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037917708

From erikj at openjdk.org  Thu Apr 10 17:37:26 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 10 Apr 2025 17:37:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <4fRjwM-P0XuOWk9QjYl9zji51zLn7wwsFKlo7tJt3JM=.976560e0-39c6-4633-bc8d-279deb1ebea3@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2757703868

From naoto at openjdk.org  Thu Apr 10 17:41:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Apr 2025 17:41:25 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <7hmmP0I0kH0UiF8cV-CkNnpdQFkddrt3TYEkFltoj8U=.3bf6bcbf-3771-4628-82e0-f678f7366d8a@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2757716905

From shade at openjdk.org  Thu Apr 10 18:21:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 18:21:31 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
Message-ID: <Wipqe979U6RClH4hM68L7BGL6n1Y2dJKmX-Ws10mP80=.26cc14b1-fbdc-4a54-873f-37709275e335@github.com>

On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.

`xtraceasm` was not released yet in any JMH version, it is going to be in 1.38. So what is the problem here? @galderz, have you dropped the snapshot JMH JARs, and it fails to run with `-prof xtraceasm`?

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

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2794755440

From eirbjo at openjdk.org  Thu Apr 10 18:33:26 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 18:33:26 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <PMuiNu8QISDQCixlTbe8T-MKLiYTln_pnbZnVAu40rA=.54d48791-965f-4c43-af22-0f9fd347aeac@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <DbpgtmWS1C9lLsRld9V1jjYvbjPycU0AkcBNF13pRhs=.d6e7773d-2278-4159-8aac-5f1ebe668404@github.com>
 <PMuiNu8QISDQCixlTbe8T-MKLiYTln_pnbZnVAu40rA=.54d48791-965f-4c43-af22-0f9fd347aeac@github.com>
Message-ID: <TSf533BmMsvDoQks6UU_84RuAPtd4-9My7aZ7yVpJYM=.930c94cf-a550-4afe-94e5-3c11342f4632@github.com>

On Thu, 10 Apr 2025 17:23:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> If this is a French name, it's e acute: ?.

Supported by this Wikipedia page listing S.L as an LCMS developer:

https://en.wikipedia.org/wiki/Little_CMS

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038022994

From eirbjo at openjdk.org  Thu Apr 10 18:45:28 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 18:45:28 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <ehtTG5WlGC5wL1RmKDo5tatGbe3N2LUN_CksKWeU4GU=.9237c820-a302-4421-97ef-612bceb71d9f@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/java.desktop/share/legal/lcms.md line 103:

> 101: Tim Zaman
> 102: Amir Montazery and Open Source Technology Improvement Fund (ostif.org), Google, for fuzzer fundings.
> 103: ```

This introduces an empty trailing line. I see you have removed trailing whitespace elsewhere.

Was this intentional, to avoid the file ending with the three ticks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038071768

From jlu at openjdk.org  Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
> 
> 
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
>   ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
>   Unicode text, UTF-8 text, with very long lines (322)
> 
> 
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598

From eirbjo at openjdk.org  Thu Apr 10 19:09:35 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 19:09:35 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <XE-3s8jHp-I5-Z7AJFz8s_D0z_FHBOWBFXWAlYQ4X8g=.3de9fb94-67d1-457c-a202-f7fb7b099f11@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

LGTM.

There are some whitepace releated changes in this PR which seem okay, but has no mention in either the JBS or PR description.

Perhaps a short mention of this intention in either place would be good for future historians.

(BTW, I enjoyed seeing separate commits for the encoding and BOM changes, makes it easier to verify each!)

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

Marked as reviewed by eirbjo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24566#pullrequestreview-2758055634

From rriggs at openjdk.org  Thu Apr 10 19:29:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 19:29:26 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <wu9Yglb_xOSAJlvORai-Lykt2Xc5n08o1cMDHeJZHGU=.0d40dc5f-cd03-412d-a482-5d4bad13a992@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

The format and presentation looks fine. 
I did not review the implementation.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23395#pullrequestreview-2758114095

From mikael at openjdk.org  Thu Apr 10 21:18:41 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 10 Apr 2025 21:18:41 GMT
Subject: Integrated: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <ki3Wjcyv_R7bKlN0GHz14GeEo7leyk_ELfH9Dg-Qmx0=.4542d7c3-ab8f-4d7a-922e-3c09ae37db9a@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

This pull request has now been integrated.

Changeset: 7382ea1a
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7382ea1a7e8570be0ff6d79d6565bfde7dd844f5
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8354230: Wrong boot jdk for alpine-linux-x64 in GHA

Reviewed-by: erikj, iris, djelinski, sgehwolf

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

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

From mikael at openjdk.org  Thu Apr 10 21:18:40 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 10 Apr 2025 21:18:40 GMT
Subject: RFR: 8354230: Wrong boot jdk for alpine-linux-x64 in GHA
In-Reply-To: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
References: <y0c1SOqev7Irjq2v7mwYwoT0JjSNogBOx7vNxoXRagc=.907d92ff-2e88-404f-866a-358069dc38f4@github.com>
Message-ID: <9qIwSiqy9PrSEwbN3gADtzD2eMCABPpPkUM7FM5LpQE=.9fc1dded-a2e1-4f0f-b4ed-64485de2b15e@github.com>

On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum boot jdk to JDK 24, and update the boot JDKs used in GHA in the process. Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to use the linux-*aarch64* version.
> 
> Testing: GHA, incl. explicitly triggering/building of alpine-linux-x64

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24557#issuecomment-2795181249

From ihse at openjdk.org  Thu Apr 10 21:28:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:31 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <lnC8HBTU5p3HB8SKi--LpFbVQqPy0KoutZAtHbtjKPY=.5681debd-f62c-41e1-b9e3-4881c996968d@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

The whitespace changes are my editor removing whitespaces at the end of a line. This is a thing we enforce for many files types, but the check does not yet formally include .txt files. I have been working from time to time with trying to extend the set of files covered by this check, so I have in general not tried to circumvent my editor when it strips trailing whitespaces even for files that we do not yet require no trailing whitespaces in jcheck.

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

PR Comment: https://git.openjdk.org/jdk/pull/24566#issuecomment-2795201480

From ihse at openjdk.org  Thu Apr 10 21:28:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:32 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <XE-3s8jHp-I5-Z7AJFz8s_D0z_FHBOWBFXWAlYQ4X8g=.3de9fb94-67d1-457c-a202-f7fb7b099f11@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <XE-3s8jHp-I5-Z7AJFz8s_D0z_FHBOWBFXWAlYQ4X8g=.3de9fb94-67d1-457c-a202-f7fb7b099f11@github.com>
Message-ID: <1IvhgoM9LMGg7s2kq_N0V7F1GCh-xFBnauZ9Ajk2Txo=.672329ea-e4c9-437c-a8b7-0502a9fdd414@github.com>

On Thu, 10 Apr 2025 19:06:35 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> (BTW, I enjoyed seeing separate commits for the encoding and BOM changes, makes it easier to verify each!)

Thanks! I do very much like myself to review PRs that has separate logical commits, so I try to produce such myself. I'm glad to hear it was appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24566#issuecomment-2795203125

From ihse at openjdk.org  Thu Apr 10 21:28:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 21:28:32 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <TSf533BmMsvDoQks6UU_84RuAPtd4-9My7aZ7yVpJYM=.930c94cf-a550-4afe-94e5-3c11342f4632@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <DbpgtmWS1C9lLsRld9V1jjYvbjPycU0AkcBNF13pRhs=.d6e7773d-2278-4159-8aac-5f1ebe668404@github.com>
 <PMuiNu8QISDQCixlTbe8T-MKLiYTln_pnbZnVAu40rA=.54d48791-965f-4c43-af22-0f9fd347aeac@github.com>
 <TSf533BmMsvDoQks6UU_84RuAPtd4-9My7aZ7yVpJYM=.930c94cf-a550-4afe-94e5-3c11342f4632@github.com>
Message-ID: <lC4QAcBHou3BhgUpPjKlqhpVBtP1qz-inSVHC4m-PtQ=.023c063c-b3e9-49dd-9055-1f1e77a24b92@github.com>

On Thu, 10 Apr 2025 18:30:22 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> If this is a French name, it's e acute: ?.
>
>> If this is a French name, it's e acute: ?.
> 
> Supported by this Wikipedia page listing S.L as an LCMS developer:
> 
> https://en.wikipedia.org/wiki/Little_CMS

It's not a mistake in capitalization, it's a mistake for two different characters in two different encodings. (Probably iso-8859-1 mistaken as ansi iirc.)

I verified the developers name at the original file in the LCMS repo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038362034

From serb at openjdk.org  Fri Apr 11 03:37:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Apr 2025 03:37:29 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <ck1TMaERYS9DrlhMUjW0gJ2pS8aAPGxQiIsutCODhH0=.6fdfddef-4377-4281-a4ca-c07969149c21@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:

> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ??????
 ????  (ISO 10646) .
> 10: 
> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ???
 ? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.

Looks like most of the changes in java2d/* are related to spaces at the end of the line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2038746193

From clanger at openjdk.org  Fri Apr 11 07:27:27 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 11 Apr 2025 07:27:27 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v5]
In-Reply-To: <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <PnRZ-wrD_whh9dKQHS-CbJScYLKBdWDEYyZuwUdJeLA=.bb63f970-6342-49d5-bf47-7c63bf937dfe@github.com>
Message-ID: <f7Xr8Fkhi-UjZ1YQwtMEgtUaThR5P-7qKQ1jnxoXVDc=.447bf4b7-27ab-437b-b0e4-d70384485d08@github.com>

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
>> 
>> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
>> 
>> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
>> 2. For those files the hash sum checks are skipped.
>> 
>> **Testing**
>> 
>> - [x] GHA
>> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14376644254))
>> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use *.conf for upgrade files

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24388#pullrequestreview-2759397284

From clanger at openjdk.org  Fri Apr 11 07:27:29 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 11 Apr 2025 07:27:29 GMT
Subject: RFR: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493 [v2]
In-Reply-To: <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
 <ndechglyfLLpH36pG2ZwvCOBEoJZubeB8L9TC2ID22o=.4a98618a-cc98-4b5c-ba98-7b4356c877a4@github.com>
 <Dnk91wohDwMV_IM0-4ZGpV8EDD9GyxbD7LwqTyFnwbk=.ec375d12-aa0c-4354-8b37-5cd01373a598@github.com>
Message-ID: <QLW0J_yoTZzd0NRFIrdTulmbyGHNpzmxs1g-FbZcXes=.586ec70d-c9ed-4fda-a006-e62d83d5264f@github.com>

On Sat, 5 Apr 2025 04:49:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Reboot upgradeable files approach
>>  - Revert "8353185: Introduce the concept of upgradeable files in context of JEP 493"
>>    
>>    This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7.
>>  - Merge branch 'master' into jdk-8353185-upgradable-files-jep493
>>  - 8353185: Introduce the concept of upgradeable files in context of JEP 493
>
> Just a few fly-by findings, no full review.
> 
> I see that you're actively on the upgradeable files. What about #24190? (@AlanBateman, what are your thoughts, how could we progress there?)

> @RealCLanger Are you OK with the latest patch (as far as your comments are concerned)?

Yes, looks good. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2796074272

From ihse at openjdk.org  Fri Apr 11 10:27:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <ck1TMaERYS9DrlhMUjW0gJ2pS8aAPGxQiIsutCODhH0=.6fdfddef-4377-4281-a4ca-c07969149c21@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <ck1TMaERYS9DrlhMUjW0gJ2pS8aAPGxQiIsutCODhH0=.6fdfddef-4377-4281-a4ca-c07969149c21@github.com>
Message-ID: <Bse7j4XXAczjL0ex434cn99r8gF-3NYz8pT1R7bKdSY=.fc21904b-15d7-489a-8012-8e8e48055afe@github.com>

On Fri, 11 Apr 2025 03:35:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
>> 
>> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
>> 
>> Methodology used: 
>> 
>> I have run four different tools for using different heuristics for determining the encoding of a file:
>> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
>> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
>> * enca (targeted towards obscure code pages)
>> * libmagic / `file  --mime-encoding`
>> 
>> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
>> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
>> 
>> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
>> * All files where at least one tool claimed it to be UTF-8
>> * All files where at least one tool claimed it to be *not* UTF-8
>> 
>> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
>> 
>> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure...
>
> src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:
> 
>> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ?????
 ?????  (ISO 10646) .
>> 10: 
>> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ??
 ?? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.
> 
> Looks like most of the changes in java2d/* are related to spaces at the end of the line?

No, that are just incidental changes (see https://github.com/openjdk/jdk/pull/24566#issuecomment-2795201480). The actual change for the java2d files is the removal of the initial UTF-8 BOM. Github has a hard time showing this though, since the BOM is not visible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2039258980

From eirbjo at openjdk.org  Fri Apr 11 10:27:40 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: RFR: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <Bse7j4XXAczjL0ex434cn99r8gF-3NYz8pT1R7bKdSY=.fc21904b-15d7-489a-8012-8e8e48055afe@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
 <ck1TMaERYS9DrlhMUjW0gJ2pS8aAPGxQiIsutCODhH0=.6fdfddef-4377-4281-a4ca-c07969149c21@github.com>
 <Bse7j4XXAczjL0ex434cn99r8gF-3NYz8pT1R7bKdSY=.fc21904b-15d7-489a-8012-8e8e48055afe@github.com>
Message-ID: <Q-oXr_T9hYeOPZPiYcutL9KzOy-U2BZp2lApku99750=.24bea4e0-cde8-4688-a950-637fcbb7d9ab@github.com>

On Fri, 11 Apr 2025 10:21:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/demo/share/java2d/J2DBench/resources/textdata/arabic.ut8.txt line 11:
>> 
>>> 9: ???????? ???????????? ?????????????? "??????????????" ???????? ?????????? ?????? ???????? ???? ???????? ???????????? ?????????????????? ???????? ?????? ?????????? ???? ?????? ?????????????? ???? ?????????????? ??????????????????. ?????? ?????? ???????? ???????????? "??????????????" ???????? ???????? ???????? ???????????????? ???????????? ???????????????? ?????? ?????????????? ?????? ?????????? ????.????.????. (IBM)?? ???????? (APPLE)?? ???????????????????? ?????????????? (Hewlett-Packard) ?? ???????????????????? (Microsoft)?? ???????????????? (Oracle) ?? ???? (Sun) ????????????. ?????? ???? ?????????????????? ?????????????????? ?????????????? (?????? ?????? ?????????????? "????????" "JAVA" ???????? "?????? ???? ????" "XML" ???????? ???????????? ???????????? ??????????????????) ?????????? ?????????????? "??????????????". ?????????? ?????? ?????? ?? ?????? "??????????????" ???? ???????????????????? ???????????????? ???????????? ???????????????? ???????????????????? ???????? ????
 ??????  (ISO 10646) .
>>> 10: 
>>> 11: ???? ???????? ???????????? "??????????????" ?????????????? ?????????????? ???????? ?????????????? ?????????????? ?????????? ???? ?????? ???????????????????? ?????????????? ???? ?????????? ?????????????????? ?????????? ???????????? ???? ????????????. ?????? ?????????????? "??????????????" ???? ???????? ?????????????????? ?????????? ?????? ?????????? ???????? ???????????? ???? ?????????????? ?????????????????? ?????????????????? ?????????????? ??????????????. ?????? ???? ?????????????? "??????????????" ???????????????? ?????????????? ???? ?????????? ???????????????? ?????? ???????????? ?????????????????? ?????? ???? ?????? ???? ?????????????? ???? ???????????????? ???????? ?????? ???? ???????? ???? ???????????? ?????????? ?????????? ?????? ???????????? ???????????? ?????????????? ???? ?????????? ???? ??????????. ?????????????? ?????? ?????????????? "??????????????" ?????????? ???????????????? ???? ???????????????? ?????? ?????????????? ???????????????? ???????????????? ?????? ?
 ??? ?????????? ?????????????????? ???????? ?????????? ?????????????? ?????????????? ?????????????? ???????????????? ???????????? ???????? ?????? ???? ???????????? ?????? ????????????????.
>> 
>> Looks like most of the changes in java2d/* are related to spaces at the end of the line?
>
> No, that are just incidental changes (see https://github.com/openjdk/jdk/pull/24566#issuecomment-2795201480). The actual change for the java2d files is the removal of the initial UTF-8 BOM. Github has a hard time showing this though, since the BOM is not visible.

I found the side-by-side diff in IntelliJ useful here, as it said "UTF-8 BOM" vs. "UTF-8".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2039263227

From ihse at openjdk.org  Fri Apr 11 10:27:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Apr 2025 10:27:40 GMT
Subject: Integrated: 8354266: Fix non-UTF-8 text encoding
In-Reply-To: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
References: <o-aAK9yjG1zWpYUQ-FuC0Y7BAIS43e5ut9--MJyN7yA=.524a9127-fda8-4e49-b9c6-d9771ba26a8a@github.com>
Message-ID: <dUBKnUnUITEbL9lDbO1jZzm3HWQMOHW-IkJRiRSMuZY=.8aac4dac-75b2-4918-bd21-8f186b6f162e@github.com>

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. 
> 
> BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of the Unicode Consortium: "Use of a BOM is neither required nor recommended for UTF-8". We have UTF-8 BOMs in a handful of files. These should be removed.
> 
> Methodology used: 
> 
> I have run four different tools for using different heuristics for determining the encoding of a file:
> * chardetect (the original, slow-as-molasses Perl program, which also had the worst performing heuristics of all; I'll rate it 1/5)
> * uchardet (a modern version by freedesktop, used by e.g. Firefox)
> * enca (targeted towards obscure code pages)
> * libmagic / `file  --mime-encoding`
> 
> They all agreed on pure ASCII files (which is easy to check), and these I just ignored/accepted as good. The handling of pure binary files differed between the tools; most detected them as binary but some suggested arcane encodings for specific (often small) binary files. To keep my sanity, I decided that files ending in any of these extensions were binary, and I did not check them further:
> * `gif|png|ico|jpg|icns|tiff|wav|woff|woff2|jar|ttf|bmp|class|crt|jks|keystore|ks|db`
> 
> From the remaining list of non-ascii, non-known-binary files I selected two overlapping and exhaustive subsets:
> * All files where at least one tool claimed it to be UTF-8
> * All files where at least one tool claimed it to be *not* UTF-8
> 
> For the first subset, I checked every non-ASCII character (using `C_ALL=C ggrep -H --color='auto' -P -n "[^\x00-\x7F]" $(cat names-of-files-to-check.txt)`, and visually examining the results). At this stage, I found several files where unicode were unnecessarily used instead of pure ASCII, and I treated those files separately. Other from that, my inspection revealed no obvious encoding errors. This list comprised of about 2000 files, so I did not spend too much time on each file. The assumption, after all, was that these files are okay.
> 
> For the second subset, I checked every non-ASCII character (using the same method). This list was about 300+ files. Most of them were okay far as I can tell; I can confirm encodings for European languages 100%, but JCK encodings could theoretically be wrong; they looked sane but I cannot read and confirm fully. Several were in fact pure binary files, but without any telling exten...

This pull request has now been integrated.

Changeset: d4e194bc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4e194bc463ff3ad09e55cbb96bea00283679ce6
Stats:     32 lines in 13 files changed: 0 ins; 2 del; 30 mod

8354266: Fix non-UTF-8 text encoding

Reviewed-by: rgiulietti, erikj, naoto, eirbjo

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

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

From hannesw at openjdk.org  Fri Apr 11 13:28:38 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 11 Apr 2025 13:28:38 GMT
Subject: Integrated: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <qBdDAnlE3gZAVw3_kt-Za50aPwWfjH9I_Ba9Om164Og=.cd11631b-115b-4c8d-89dc-9b03a91703e6@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

This pull request has now been integrated.

Changeset: 2321722a
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2321722a45c0ae8a2fd0aabfa2aa01d3b801c832
Stats:     357 lines in 8 files changed: 297 ins; 39 del; 21 mod

8346109: Create JDK taglet for additional preview notes

Reviewed-by: ihse, liach, rriggs

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

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

From hannesw at openjdk.org  Fri Apr 11 13:36:31 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 11 Apr 2025 13:36:31 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
Message-ID: <rszEuHsO65WALwZFYInXXxZ6LapjuSKP7zgLo284eGo=.d20fa999-8e0e-463b-bc1b-72dc4bdfce50@github.com>

On Fri, 31 Jan 2025 16:19:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a patch to add a JavaDoc Taglet to the JDK build system that allows to add preview-related notes to non-preview API elements, as well as a hidden javadoc option to add elements with preview notes to the preview summary page.
> 
> The {@previewNote} tag uses the following syntax:
> 
> 
> {@previewNote <jep-number> [preview note title]}
> preview note text
> {@previewNote}
> ``` 
> 
> Elements with preview notes are listed in a separate table titled "Elements containing Preview Notes" in the preview summary page. 
> 
> To support the feature, the algorithm in `PreviewAPIListBuilder.java` was changed to retrieve the preview JEP info in advance before looping through API elements. While this is not strictly necessary, it makes the code a bit nicer, and it also allows us to avoid checking for preview API elements when processing non-JDK code.

I went ahead and integtated the PR. We can improve the feature based on how it works out in actual use.

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

PR Comment: https://git.openjdk.org/jdk/pull/23395#issuecomment-2796934892

From hannesw at openjdk.org  Fri Apr 11 13:36:32 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 11 Apr 2025 13:36:32 GMT
Subject: RFR: 8346109: Create JDK taglet for additional preview notes
In-Reply-To: <3g1znPCkrXwFs7KpaCvr6A6bfVyt68phdhDnNZRmluU=.61114b79-03ff-4be4-a0a0-f92c985eb3e2@github.com>
References: <avcdvU84tTKWNWGG347UIHO5vxxNRXS7bx0zLlqXr8Q=.c3fa0b14-29a0-4778-baf1-1121873206d9@github.com>
 <hJ2xar2yzIflrEYvM-TDkpM3rEjMVyDO5DZ_HATqPKs=.d82d571b-dcd3-44d6-ac53-b08ef7332ca2@github.com>
 <w7qcGyLJDYa1FEDKkLUwwFOfObZ4iWlpT19DNzKKgL0=.248506cf-3358-44dd-8bd8-6dc1dbc18eee@github.com>
 <OMy7sMBk684K5PEPRaXr7Z2F6ugHdOlad4iyxuMphrY=.474a4fd3-8ef1-4638-9fb1-3bbb513c0f45@github.com>
 <Vh2hgbQchDfdIPcIiF1Ab2Af8tdRRDtgxv7eIqcx9y4=.007e265a-ff8a-47d9-9176-5e088a843b06@github.com>
 <3g1znPCkrXwFs7KpaCvr6A6bfVyt68phdhDnNZRmluU=.61114b79-03ff-4be4-a0a0-f92c985eb3e2@github.com>
Message-ID: <PVqwlrGNNreKcPgbJksqz19U7WsRjDvO9EM8NXeethU=.6b4fdde9-f6e3-4500-855b-47c3eb871fa3@github.com>

On Tue, 8 Apr 2025 18:32:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The problem is the Taglet class is part of the build system, and I don't think we have a way to test these build classes (I coulndn't find any tests for the other build Taglets). I could replicate the Taglet class in the test, but that doesn't seem like a good solution either.
>
> Can we have a usage example of this tag somewhere then?

There is a usage example in the Taglet class comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23395#discussion_r2039572878

From ihse at openjdk.org  Sun Apr 13 22:50:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 22:50:37 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8
Message-ID: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>

This is a WIP to move the JDK source code base to fully UTF-8, and to ensure tools knows about this.

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

Commit messages:
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - Don't convert properties files to iso-8859-1.
 - Tell tools we use utf-8
 - Replace iso-8859-1 encodings with utf-8 in source code
 - Explain reason for non-UTF-8 character in JDK_RCFLAGS

Changes: https://git.openjdk.org/jdk/pull/24574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301971
  Stats: 130 lines in 8 files changed: 17 ins; 103 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

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

From ihse at openjdk.org  Sun Apr 13 22:58:26 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 22:58:26 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <0io2A_4xFMiR8rwbXPPyYyXar_fwE1jG4K81pY_heUU=.18d9f809-dafc-4900-82fa-6478eb50b8de@github.com>

On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

I would like to run proper tests to verify the changes in libjava, but I don't know what tests that would be. If anyone can enlighten me, please do. 

(I suspect that the code did not really work properly before, and that the specially encoded characters where not thoroughly tested, but I can be wrong.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2800165519

From ihse at openjdk.org  Sun Apr 13 23:14:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 13 Apr 2025 23:14:41 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <fzA9WkdIWsUw7bq4kEATu0w6n0R_unnwe4LsvKLBVVE=.d67b23a2-30bd-4202-b555-d321f1b1539a@github.com>

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

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

  Also tell javadoc that we have utf-8 now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/4fb897ef..38004164

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

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

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

From ihse at openjdk.org  Mon Apr 14 12:53:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 14 Apr 2025 12:53:35 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

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

 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/38004164..452f42dc

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

  Stats: 47 lines in 7 files changed: 27 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

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

From kbarrett at openjdk.org  Mon Apr 14 12:53:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 12:53:53 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: <fzA9WkdIWsUw7bq4kEATu0w6n0R_unnwe4LsvKLBVVE=.d67b23a2-30bd-4202-b555-d321f1b1539a@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <fzA9WkdIWsUw7bq4kEATu0w6n0R_unnwe4LsvKLBVVE=.d67b23a2-30bd-4202-b555-d321f1b1539a@github.com>
Message-ID: <Hnxung3fSH6ENQBFItYy8r7okqWkUVS-iYYTB7bvUfs=.ac4d354e-2eec-4d7f-b0c6-a9cd55e56d8c@github.com>

On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also tell javadoc that we have utf-8 now

A couple of drive-by comments.  Don't count me as a Reviewer for this.

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

> 575:   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
> 576:     # The -utf-8 option sets source and execution character sets to UTF-8 to enable correct
> 577:     # compilation of all source files regardless of the active code page on Windows.

Seems like this comment should be updated and moved near the new code block for setting up `CHARSET_CFLAGS`.

make/common/JavaCompilation.gmk line 83:

> 81: # The sed expression does this:
> 82: # 1. Add a backslash before any :, = or ! that do not have a backslash already.
> 83: # 3. Delete all lines starting with #.

There is no item 2 anymore, so following bullets are misnumbered.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2762999364
PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2041326051
PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2041328098

From ihse at openjdk.org  Mon Apr 14 12:53:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 14 Apr 2025 12:53:56 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v2]
In-Reply-To: <fzA9WkdIWsUw7bq4kEATu0w6n0R_unnwe4LsvKLBVVE=.d67b23a2-30bd-4202-b555-d321f1b1539a@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <fzA9WkdIWsUw7bq4kEATu0w6n0R_unnwe4LsvKLBVVE=.d67b23a2-30bd-4202-b555-d321f1b1539a@github.com>
Message-ID: <tskutEmK8BsYzQiMef2mgWk0qz-bTvL47qG0Li-44_Y=.8018aaa8-1927-41dd-b4ad-3bb3cdeaf11a@github.com>

On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also tell javadoc that we have utf-8 now

Inspired by [Phil's comment in JDK-8353948](https://bugs.openjdk.org/browse/JDK-8353948?focusedId=14769043&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14769043), I also modified configure to only allow utf-8 environments, but to also allow `en_US.UTF-8` as a valid locale. 

This also resolves [JDK-8333247](https://bugs.openjdk.org/browse/JDK-8333247) in a better way.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2800741990

From mbaesken at openjdk.org  Mon Apr 14 13:03:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Apr 2025 13:03:19 GMT
Subject: Integrated: 8354254: Remove the linux ppc64
 -minsert-sched-nops=regroup_exact compile flag
In-Reply-To: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
References: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
Message-ID: <3wsBfKCgPiSOoigxeTaoos165-8ygbVmMoEVAbGNJJo=.02280490-5a92-49ea-a62d-1827d4007de3@github.com>

On Thu, 10 Apr 2025 08:19:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On linux ppc64 / gcc , we build with the compile flag -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it was still useful for old Power6 machines.
> 
> See https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS_002f6000-and-PowerPC-Options.html
> -minsert-sched-nops=scheme : This option controls which NOP insertion scheme is used during the second scheduling pass. The argument scheme takes one of the following values:
> ?regroup_exact? : Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.

This pull request has now been integrated.

Changeset: f8ae1d4e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8ae1d4e6cd317eaa98835a209366b9d504feb44
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8354254: Remove the linux ppc64 -minsert-sched-nops=regroup_exact compile flag

Reviewed-by: erikj, mdoerr

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

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

From mbaesken at openjdk.org  Mon Apr 14 13:03:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Apr 2025 13:03:18 GMT
Subject: RFR: 8354254: Remove the linux ppc64
 -minsert-sched-nops=regroup_exact compile flag
In-Reply-To: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
References: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
Message-ID: <dhOICWhOsQxu99SAvVYd1pmuK1ah79poMRqBlMFfxD8=.de53345c-64a3-4f9e-b324-dc3edc640690@github.com>

On Thu, 10 Apr 2025 08:19:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On linux ppc64 / gcc , we build with the compile flag -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it was still useful for old Power6 machines.
> 
> See https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS_002f6000-and-PowerPC-Options.html
> -minsert-sched-nops=scheme : This option controls which NOP insertion scheme is used during the second scheduling pass. The argument scheme takes one of the following values:
> ?regroup_exact? : Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.

Erik and Martin, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/24564#issuecomment-2800928953

From mdoerr at openjdk.org  Mon Apr 14 13:03:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Apr 2025 13:03:17 GMT
Subject: RFR: 8354254: Remove the linux ppc64
 -minsert-sched-nops=regroup_exact compile flag
In-Reply-To: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
References: <VrWUYJ7d7wuOsTFnVcHUxXoLQanOjddS21RPKgXsNb4=.385a0164-2040-4c3c-8ef3-378581b5bea7@github.com>
Message-ID: <0gyEYCPXdlNNMVxcGaA7j_yW9VGM0It3r-_sdVuhlAw=.713c9c9c-70a1-45f1-921a-8fef5478af99@github.com>

On Thu, 10 Apr 2025 08:19:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On linux ppc64 / gcc , we build with the compile flag -minsert-sched-nops=regroup_exact ; this is most likely outdated, maybe it was still useful for old Power6 machines.
> 
> See https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/RS_002f6000-and-PowerPC-Options.html
> -minsert-sched-nops=scheme : This option controls which NOP insertion scheme is used during the second scheduling pass. The argument scheme takes one of the following values:
> ?regroup_exact? : Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24564#pullrequestreview-2763498735

From aboldtch at openjdk.org  Mon Apr 14 13:32:51 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 14 Apr 2025 13:32:51 GMT
Subject: RFR: 8354510: Skipped gtest cause test failure
Message-ID: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>

`GTEST_SKIPPED` tests count is accounted in gtests run. But when we calculate the number of GTEST errors we take `ERROR = RUN - PASSED - FAILED`. We need parse and account for the skipped as well. Currently we only account for `DISABLED` gtests (which are not counted as run tests). 

This patch adds support for both `DISABLED` and `GTEST_SKIPPED` tests.

So with this patch we end up with: 
`ERROR = RUN - PASSED - FAILED - GTEST_SKIPPED`
`SKIPPED = GTEST_SKIPPED + GTEST_DISABLED `

Verified that this works locally on MacOS and Linux. Currently running through testing and GHA. 

_The old `match` expression was problematic with some awk, not sure if there was some other reason it was used, rather than the style used elsewhere `maybe set, if unset set=0`_

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

Commit messages:
 - 8354510: Skipped gtest cause test failure

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

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

From rehn at openjdk.org  Mon Apr 14 13:58:46 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Apr 2025 13:58:46 GMT
Subject: RFR: 8354510: Skipped gtest cause test failure
In-Reply-To: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
References: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
Message-ID: <IFjBu1x6vz36gkbRCS_V84YipOHQU7XkZbF4ILRRAOQ=.126044d9-7b91-49e2-9f33-2cf969046432@github.com>

On Mon, 14 Apr 2025 13:25:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `GTEST_SKIPPED` tests count is accounted in gtests run. But when we calculate the number of GTEST errors we take `ERROR = RUN - PASSED - FAILED`. We need parse and account for the skipped as well. Currently we only account for `DISABLED` gtests (which are not counted as run tests). 
> 
> This patch adds support for both `DISABLED` and `GTEST_SKIPPED` tests.
> 
> So with this patch we end up with: 
> `ERROR = RUN - PASSED - FAILED - GTEST_SKIPPED`
> `SKIPPED = GTEST_SKIPPED + GTEST_DISABLED `
> 
> Verified that this works locally on MacOS and Linux. Currently running through testing and GHA. 
> 
> _The old `match` expression was problematic with some awk, not sure if there was some other reason it was used, rather than the style used elsewhere `maybe set, if unset set=0`_

Works fine at my end, looks fine, thank you!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24622#pullrequestreview-2764435626

From erikj at openjdk.org  Mon Apr 14 13:58:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Apr 2025 13:58:46 GMT
Subject: RFR: 8354510: Skipped gtest cause test failure
In-Reply-To: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
References: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
Message-ID: <sWwfjjOnFLeL_slCxi5WwuuhXE5e0s911j9CEjWXJ-k=.f069e863-324d-450b-9c35-4f41486739a0@github.com>

On Mon, 14 Apr 2025 13:25:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `GTEST_SKIPPED` tests count is accounted in gtests run. But when we calculate the number of GTEST errors we take `ERROR = RUN - PASSED - FAILED`. We need parse and account for the skipped as well. Currently we only account for `DISABLED` gtests (which are not counted as run tests). 
> 
> This patch adds support for both `DISABLED` and `GTEST_SKIPPED` tests.
> 
> So with this patch we end up with: 
> `ERROR = RUN - PASSED - FAILED - GTEST_SKIPPED`
> `SKIPPED = GTEST_SKIPPED + GTEST_DISABLED `
> 
> Verified that this works locally on MacOS and Linux. Currently running through testing and GHA. 
> 
> _The old `match` expression was problematic with some awk, not sure if there was some other reason it was used, rather than the style used elsewhere `maybe set, if unset set=0`_

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24622#pullrequestreview-2764439775

From kbarrett at openjdk.org  Mon Apr 14 17:36:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Apr 2025 17:36:47 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <mEnCXrJfI3IkIEGX0dN4eavpak5FryWdnLIie3HbkTw=.15a6510c-095d-491c-b71b-6a49d3377f5b@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

My comments have been addressed.  Let's see if this is sufficient to clear my
"request changes" state.

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2765099003

From aboldtch at openjdk.org  Tue Apr 15 05:14:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 15 Apr 2025 05:14:48 GMT
Subject: RFR: 8354510: Skipped gtest cause test failure
In-Reply-To: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
References: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
Message-ID: <P4GLlSjYwJiJiAvqO3muCITr1suIUyN1fxtqpr3BI7c=.ecd62744-698f-449c-a37c-b5cbbf23085a@github.com>

On Mon, 14 Apr 2025 13:25:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `GTEST_SKIPPED` tests count is accounted in gtests run. But when we calculate the number of GTEST errors we take `ERROR = RUN - PASSED - FAILED`. We need parse and account for the skipped as well. Currently we only account for `DISABLED` gtests (which are not counted as run tests). 
> 
> This patch adds support for both `DISABLED` and `GTEST_SKIPPED` tests.
> 
> So with this patch we end up with: 
> `ERROR = RUN - PASSED - FAILED - GTEST_SKIPPED`
> `SKIPPED = GTEST_SKIPPED + GTEST_DISABLED `
> 
> Verified that this works locally on MacOS and Linux. Currently running through testing and GHA. 
> 
> _The old `match` expression was problematic with some awk, not sure if there was some other reason it was used, rather than the style used elsewhere `maybe set, if unset set=0`_

Thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/24622#issuecomment-2803823273

From aboldtch at openjdk.org  Tue Apr 15 05:14:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 15 Apr 2025 05:14:48 GMT
Subject: Integrated: 8354510: Skipped gtest cause test failure
In-Reply-To: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
References: <8FB1dr3UporGHcVltG_QqlGdt7VFHTIhxYxUJzkMqCw=.e60f969b-da4b-46bf-b335-9693d1058bf5@github.com>
Message-ID: <xcsn6mWWdpYU-kF64O9KW6gt8BoHtPtJNDk5SvSgTVw=.29f4c1f2-5396-4525-8a43-bf2de4118410@github.com>

On Mon, 14 Apr 2025 13:25:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `GTEST_SKIPPED` tests count is accounted in gtests run. But when we calculate the number of GTEST errors we take `ERROR = RUN - PASSED - FAILED`. We need parse and account for the skipped as well. Currently we only account for `DISABLED` gtests (which are not counted as run tests). 
> 
> This patch adds support for both `DISABLED` and `GTEST_SKIPPED` tests.
> 
> So with this patch we end up with: 
> `ERROR = RUN - PASSED - FAILED - GTEST_SKIPPED`
> `SKIPPED = GTEST_SKIPPED + GTEST_DISABLED `
> 
> Verified that this works locally on MacOS and Linux. Currently running through testing and GHA. 
> 
> _The old `match` expression was problematic with some awk, not sure if there was some other reason it was used, rather than the style used elsewhere `maybe set, if unset set=0`_

This pull request has now been integrated.

Changeset: 76ff9781
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76ff97811abf5a4eaede6303e25ff9582302e436
Stats:     11 lines in 1 file changed: 0 ins; 1 del; 10 mod

8354510: Skipped gtest cause test failure

Reviewed-by: rehn, erikj

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

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

From jpai at openjdk.org  Tue Apr 15 05:57:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Apr 2025 05:57:19 GMT
Subject: RFR: 8354565: jtreg failure handler GatherProcessInfoTimeoutHandler
 has a leftover call to System.loadLibrary
Message-ID: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>

Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?

As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 

I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

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

Commit messages:
 - 8354565: jtreg failure handler GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary

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

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

From alanb at openjdk.org  Tue Apr 15 06:00:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 06:00:39 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
References: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
Message-ID: <bPJa8SO7I699BV-OcpD6Qam0VvHsxJcuy5t9XKPg4v8=.8c2fa23f-b0ca-4326-963c-7d66be709aea@github.com>

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Good

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24648#pullrequestreview-2766888348

From kbarrett at openjdk.org  Tue Apr 15 06:03:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Apr 2025 06:03:40 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
References: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
Message-ID: <c-elalCRDKEEYVsAgK24uCl79qPJCnOSZkCGCGII8CA=.8a2b9756-d3fa-4d68-9d3b-aa6545ca66ee@github.com>

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24648#pullrequestreview-2766895709

From galder at openjdk.org  Tue Apr 15 09:12:46 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 15 Apr 2025 09:12:46 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <Wipqe979U6RClH4hM68L7BGL6n1Y2dJKmX-Ws10mP80=.26cc14b1-fbdc-4a54-873f-37709275e335@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
 <Wipqe979U6RClH4hM68L7BGL6n1Y2dJKmX-Ws10mP80=.26cc14b1-fbdc-4a54-873f-37709275e335@github.com>
Message-ID: <F0hcxuWEHcv60Xe0ENxCb0hU3ghWgEQD020AZKlvgYw=.64498898-d6c2-4546-af4f-21c3358320ae@github.com>

On Thu, 10 Apr 2025 18:18:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.
>
> `xtraceasm` was not released yet in any JMH version, it is going to be in 1.38. So what is the problem here? @galderz, have you dropped the snapshot JMH JARs, and it fails to run with `-prof xtraceasm`?

@shipilev Yes I'm using the latest JMH source code snapshot to try out xtrace profiler locally. `-prof xctraceasm` works fine as is, but `-prof xctracenorm` fails. The problem is explained in [JDK-8354257](https://bugs.openjdk.org/browse/JDK-8354257).

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

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2804370732

From sgehwolf at openjdk.org  Tue Apr 15 10:19:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Apr 2025 10:19:55 GMT
Subject: Integrated: 8353185: Introduce the concept of upgradeable files in
 context of JEP 493
In-Reply-To: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
References: <icduW55azxgRU8JAHVL4qRjWo1jZ5Vt6nBg0SdJ8sng=.45320e12-8568-45ab-bb4a-f17238836c85@github.com>
Message-ID: <oLOS8GyNzbxIAad5eL_9vkBHG345fijzcBMys1Ng1YY=.537292af-706a-4a42-9294-67eede07fa2e@github.com>

On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> For JEP 493-enabled builds there are no JMODs. Certain files come from the installed JDK image when a user creates a custom run-time from it. This is problematic for example for files that often come from a different package (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), or more generally when they get updated out-of-band of the JDK build itself like the tzupdater tool.
> 
> When that happens the hash sum recorded at JDK build time of those files no longer match, causing `jlink` to fail. I propose to allow for those files to get "upgraded" should this happen. The way this works is as follows:
> 
> 1. The list of upgradeable files is configured by a resource file in `jdk.jlink` on a per module basis. Right now, only two files from the `java.base` module will be allowed to be upgraded with a link from the current run-time image.
> 2. For those files the hash sum checks are skipped.
> 
> **Testing**
> 
> - [x] GHA
> - [x] `jdk/tools/jlink` jtreg tests (also on [GHA](https://github.com/jerboaa/jdk/actions/runs/14376644254))
> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 4e24dc00
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e24dc003c2304041b342371adf430b120a9fec8
Stats:     254 lines in 5 files changed: 250 ins; 0 del; 4 mod

8353185: Introduce the concept of upgradeable files in context of JEP 493

Reviewed-by: clanger, ihse, alanb

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

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

From mikael at openjdk.org  Tue Apr 15 16:04:28 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 15 Apr 2025 16:04:28 GMT
Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle
 [v3]
In-Reply-To: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com>
References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com>
Message-ID: <f5Io9l7IBn0pejyjNuO4j33spWO8OEfdmEAaZnX4SJ4=.8a84316e-475b-43fb-ae32-b0166a04b786@github.com>

> Background:
> 
> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0.
> 
> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed).
> 
> Testing:
> 
> Manual builds, tier1-5 + additional func & performance testing.

Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8351603-gcc-14.2.0
 - Update jib-profiles.js
 - Update doc/building.{md,html}
 - Add missing liblto_plugin.so link
 - Change to GCC 14.2.0 for building on Linux at Oracle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23975/files
  - new: https://git.openjdk.org/jdk/pull/23975/files/ac2b44db..baadf879

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

  Stats: 336870 lines in 3659 files changed: 78030 ins; 243524 del; 15316 mod
  Patch: https://git.openjdk.org/jdk/pull/23975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23975/head:pull/23975

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

From jkern at openjdk.org  Tue Apr 15 18:54:56 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 15 Apr 2025 18:54:56 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
Message-ID: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>

With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
Unfortunately there has to be some adoptions.
- Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
- ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
- The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.

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

Commit messages:
 - JDK-8354686

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

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

From duke at openjdk.org  Tue Apr 15 19:35:24 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Tue, 15 Apr 2025 19:35:24 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v4]
In-Reply-To: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
Message-ID: <kSCe9W2Aj_C4Sz1_nu_vRGSpuNdugbo0VMpFystUvoI=.6c7d1456-411d-444e-84e4-5528178e5d05@github.com>

> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.

Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:

 - Add Visual Studio Build Tools setup instructions
 - Revert "Add instructions for a native Windows AArch64 build"
   
   This reverts commit ce4a5914f40d315f39c9593bd9cdb8aa53e33ca0.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24267/files
  - new: https://git.openjdk.org/jdk/pull/24267/files/ce4a5914..01d7742c

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

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

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

From erikj at openjdk.org  Tue Apr 15 19:45:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Apr 2025 19:45:51 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
Message-ID: <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>

On Tue, 15 Apr 2025 18:40:57 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
> Unfortunately there has to be some adoptions.
> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.

make/autoconf/jdk-options.m4 line 526:

> 524:   UBSAN_LDFLAGS="$UBSAN_CHECKS"
> 525:   if test "x$TOOLCHAIN_TYPE" = "xclang" && test "x$OPENJDK_TARGET_OS" = "xaix"; then
> 526:       UBSAN_CFLAGS="$UBSAN_CFLAGS -fno-sanitize=function,vptr -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer"

I would recommend handling this tool path properly, by first trying to look it up with one of the standard macros and then falling back to a default, and let configure fail if it wasn't found. This would also implicitly add the ability for the user to specify a different path if ever needed (using VAR_NAME=/path/to/tool on the command line). However, since this isn't a platform I'm supporting, I won't force you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2045346013

From serb at openjdk.org  Tue Apr 15 23:23:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Apr 2025 23:23:46 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

can we also force this rule by the jcheck?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2807748235

From jpai at openjdk.org  Wed Apr 16 02:00:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 02:00:45 GMT
Subject: RFR: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
References: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
Message-ID: <hG5uwA11rTSZxpWVVbsPI_JRoa-jCRaCrsW_AZou-s8=.285d5cd3-9556-4192-87d3-745de42be78d@github.com>

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

Thank you Alan and Kim for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24648#issuecomment-2807986200

From jpai at openjdk.org  Wed Apr 16 02:00:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 02:00:46 GMT
Subject: Integrated: 8354565: jtreg failure handler
 GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary
In-Reply-To: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
References: <lGq39U08lPW62OJxA4IUkZI2RVT2fa5upwyb7qUhKO4=.e8363480-7aac-496d-b96e-d7079fcd6b3b@github.com>
Message-ID: <4emG32tE0Xv4LDYkwRTy1lxEt6gziQAPs2PVnjDXFAc=.9fdd9cd9-8fdf-4d55-8189-2de426d102dc@github.com>

On Tue, 15 Apr 2025 05:50:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this cleanup in the jtreg timeout handler `GatherProcessInfoTimeoutHandler`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8354565, this is a leftover after the change done in https://bugs.openjdk.java.net/browse/JDK-8268626. The `timeoutHandler` native test library is no longer built in the JDK, nor it is required by this `GatherProcessInfoTimeoutHandler`. 
> 
> I've verified that the `GatherProcessInfoTimeoutHandler` continues to function normally on macosx (x64/aarch64), linux(x64/aarch64) and windows (x64), by intentionally timing out a test and verifying that the `GatherProcessInfoTimeoutHandler` continues to gather the relevant diagnostics.

This pull request has now been integrated.

Changeset: 55264907
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5526490743a75786a40754b6805f4381ae2892b5
Stats:     12 lines in 1 file changed: 0 ins; 12 del; 0 mod

8354565: jtreg failure handler GatherProcessInfoTimeoutHandler has a leftover call to System.loadLibrary

Reviewed-by: alanb, kbarrett

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

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

From jwaters at openjdk.org  Wed Apr 16 06:07:48 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 16 Apr 2025 06:07:48 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <L3yxoZJqk1IaAqNjiCkBArwDWMe-Z0UW7UJZvHYcuF0=.0c8936af-d20f-4395-937b-02357837d391@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

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

No.

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

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

From mbaesken at openjdk.org  Wed Apr 16 06:39:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Apr 2025 06:39:42 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v4]
In-Reply-To: <kSCe9W2Aj_C4Sz1_nu_vRGSpuNdugbo0VMpFystUvoI=.6c7d1456-411d-444e-84e4-5528178e5d05@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <kSCe9W2Aj_C4Sz1_nu_vRGSpuNdugbo0VMpFystUvoI=.6c7d1456-411d-444e-84e4-5528178e5d05@github.com>
Message-ID: <q6Q81vSOqkYF23TrehpDxtXvudnzaQJ_LZS5kNzqyX8=.b46102a0-fffc-4c26-9ec8-0e12e927a4b7@github.com>

On Tue, 15 Apr 2025 19:35:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add Visual Studio Build Tools setup instructions
>  - Revert "Add instructions for a native Windows AArch64 build"
>    
>    This reverts commit ce4a5914f40d315f39c9593bd9cdb8aa53e33ca0.

The title 'Document target selection flag for ...' should be changed e.g. to  'Improve documentation for ...' or something like this.
(needs to be changed in JBS AND here)

doc/building.md line 1478:

> 1476: 
> 1477: ```
> 1478: bash configure --with-boot-jdk=$BOOT_JDK

Probably lines 1474 - 1479 are now not needed any more because they just state you have to set the boot jdk but that's nothing specific for these builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2808537794
PR Review Comment: https://git.openjdk.org/jdk/pull/24267#discussion_r2046184081

From mdoerr at openjdk.org  Wed Apr 16 07:56:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 16 Apr 2025 07:56:47 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

We get the following problem on AIX:

checking for locale to use... no UTF-8 locale found
configure: error: No UTF-8 locale found. This is required for building successfully.
configure exiting with result code 1

@varada1110, @JoKern65: Can you take a look, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2808717775

From ihse at openjdk.org  Wed Apr 16 09:50:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 09:50:49 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <7k8Vqbwnc5gQLdLWy6DMG3ReD0O68knX8T1OH4bdRZ8=.058d8240-f58f-4459-bd1e-e92981d6ae9b@github.com>
Message-ID: <kJrxY3kK9UGxsDZg3ZEONMjO3bTzWvwP54Sua11TqtE=.039e9b81-1e09-4d90-b1c0-6d3edfabdb00@github.com>

On Tue, 15 Apr 2025 23:20:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> can we also force this rule by the jcheck?

Well, yes and no. First, we can verify that we do not have invalid UTF-8. That might be a signal that the encoding is wrong. But then this check needs to be able to distinguish between pure binary files that happen to look like improperly encoded UTF-8 files, and actually incorrectly encoded text files. In the end, this is likely to be more of an heuristic for a warning, rather than something we can block integration on.

Secondly, files can have incorrect encodings but still pass as valid UTF-8. Only a human can tell that the content would be incorrect if we were to assume the encoding is UTF-8 instead of e.g. latin-1. This cannot be checked by jcheck, but must be caught by reviewers.

I have beeb thinking, though, to add a warning to jcheck for adding non-ASCII characters to known text file types. As a general rule, this is acceptable but should only be done judiciously, so it would be good to have jcheck point it out. That would also give you an extra chance to verify the encoding.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809028487

From ihse at openjdk.org  Wed Apr 16 09:55:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 09:55:40 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
Message-ID: <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>

On Wed, 16 Apr 2025 07:54:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We get the following problem on AIX:
> 
> ```
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> ```

This is (hopefully) more of a configuration issue than an issue with AIX per se. You can run `locale -a` to see all available locales, and see if there is any utf-8 locales at all. It might be that the naming scheme does not match `*.UTF-8`. Otherwise, you'd have to install the `C.UTF-8` or `en_US.UTF-8` locale. 

If no UTF-8 locales are available at all on AIX, then we might have to add some kind of exception. But beware that you will be building on an unsupported configuration in that case.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809035830

From mdoerr at openjdk.org  Wed Apr 16 10:11:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 16 Apr 2025 10:11:46 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <_OtXyj0LCymmSCQhXmO-Ak_z5ZEYd5-tvqPp16TmXos=.8da4aecf-3538-4303-9b5a-2a59811642e0@github.com>
 <6Kyy5kYllWxxLc6k2u-dF9dqmPcEQS74vEJO8rWG-D0=.0adee9b2-334c-473c-b0cc-1cbeb2774df6@github.com>
Message-ID: <v2xraBO3QNaJ33r5-sh-O00SbBQLj9A-LfWcIM7G3Yk=.d73e48bb-984e-4bcb-b368-db85c89eaec8@github.com>

On Wed, 16 Apr 2025 09:51:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> `locale -a`


C
POSIX
en_US.8859-15
en_US.IBM-858
en_US.ISO8859-1
en_US


I don't know if UTF-8 can be installed. If so, we should also document that as requirement for AIX build machines.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809046398

From ihse at openjdk.org  Wed Apr 16 10:11:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 10:11:52 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <vALExXXVPgMkAGUW_lshrTNoF1uESIaydhhMGFPsUi4=.ce59a810-9597-4291-8eea-7165710215d7@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

? It's kind of a wonder that you have been able to build at all so far..!

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2809055178

From ihse at openjdk.org  Wed Apr 16 10:11:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 10:11:57 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v4]
In-Reply-To: <kSCe9W2Aj_C4Sz1_nu_vRGSpuNdugbo0VMpFystUvoI=.6c7d1456-411d-444e-84e4-5528178e5d05@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <kSCe9W2Aj_C4Sz1_nu_vRGSpuNdugbo0VMpFystUvoI=.6c7d1456-411d-444e-84e4-5528178e5d05@github.com>
Message-ID: <1aVQCTwoBuCpTkJX6fS3-tiLhcIOteyOcJTqcX_Pf6U=.3d9ce56e-e28f-4849-96b7-97a468fa6e5d@github.com>

On Tue, 15 Apr 2025 19:35:24 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add Visual Studio Build Tools setup instructions
>  - Revert "Add instructions for a native Windows AArch64 build"
>    
>    This reverts commit ce4a5914f40d315f39c9593bd9cdb8aa53e33ca0.

doc/building.md line 1489:

> 1487:   --with-boot-jdk=$BOOT_JDK \
> 1488:   --openjdk-target=aarch64-unknown-cygwin
> 1489: ```

Suggestion:

To generate Windows AArch64 builds using Cygwin on a Windows x64 machine,
you must set the proper target platform by adding 
`--openjdk-target=aarch64-unknown-cygwin` to your configure command line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24267#discussion_r2046568547

From mbaesken at openjdk.org  Wed Apr 16 10:37:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Apr 2025 10:37:42 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

make/autoconf/basic.m4 line 155:

> 153:       else
> 154:         AC_MSG_RESULT([no UTF-8 locale found])
> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])

Seems we run into this 'else' part  on  AIX


checking for locale to use... no UTF-8 locale found
configure: error: No UTF-8 locale found. This is required for building successfully.
configure exiting with result code 1

maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2046642699

From jkern at openjdk.org  Wed Apr 16 10:43:47 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 16 Apr 2025 10:43:47 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
Message-ID: <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>

On Tue, 15 Apr 2025 19:42:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
>> Unfortunately there has to be some adoptions.
>> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
>> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
>> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.
>
> make/autoconf/jdk-options.m4 line 526:
> 
>> 524:   UBSAN_LDFLAGS="$UBSAN_CHECKS"
>> 525:   if test "x$TOOLCHAIN_TYPE" = "xclang" && test "x$OPENJDK_TARGET_OS" = "xaix"; then
>> 526:       UBSAN_CFLAGS="$UBSAN_CFLAGS -fno-sanitize=function,vptr -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer"
> 
> I would recommend handling this tool path properly, by first trying to look it up with one of the standard macros and then falling back to a default, and let configure fail if it wasn't found. This would also implicitly add the ability for the user to specify a different path if ever needed (using VAR_NAME=/path/to/tool on the command line). However, since this isn't a platform I'm supporting, I won't force you.

Can you please give me an example to try?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2046652062

From jlahoda at openjdk.org  Wed Apr 16 12:07:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Apr 2025 12:07:45 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v4]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <qjrKrdlFFACyU8RzAnukvjhB_Le4zerLkF7hubd-kZQ=.f2a5a196-4588-4452-8784-023a27922e29@github.com>

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

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

  Reflecting review feedback: Adding makefile comment as suggested

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24242/files
  - new: https://git.openjdk.org/jdk/pull/24242/files/daa2cc39..d75641e2

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

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

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

From ihse at openjdk.org  Wed Apr 16 13:44:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2025 13:44:52 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
Message-ID: <pnUBaVgmbs3IDJT3oi3tDLtyYLfZBZKG0Q9ZVH5SuqU=.4ec4bb8c-a21d-4891-be72-2d17307e4c32@github.com>

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Also document UTF-8 requirements (solves JDK-8338973)
>>  - Let configure only accept utf-8 locales
>>  - Address review comments from Kim
>
> make/autoconf/basic.m4 line 155:
> 
>> 153:       else
>> 154:         AC_MSG_RESULT([no UTF-8 locale found])
>> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])
> 
> Seems we run into this 'else' part  on  AIX
> 
> 
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> 
> maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

If you have a locale named `<something>.UTF-8` as your active locale, that will also be accepted, so it is not limited to C and en_US. But it might be an idea to include it in the error message, yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2046971091

From duke at openjdk.org  Wed Apr 16 14:41:28 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Wed, 16 Apr 2025 14:41:28 GMT
Subject: RFR: 8353009: Document target selection flag for Windows AArch64
 builds [v5]
In-Reply-To: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
Message-ID: <XiKoQv1QzWt8vexZmkVr8rmtAa83K1-1rdBkrlFMCDI=.74e1f57f-073b-442e-8532-3e4e5f06e493@github.com>

> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.

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

  Simplify documentation
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24267/files
  - new: https://git.openjdk.org/jdk/pull/24267/files/01d7742c..11e906be

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

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

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

From duke at openjdk.org  Wed Apr 16 14:50:57 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Wed, 16 Apr 2025 14:50:57 GMT
Subject: RFR: 8353009: Improve documentation for Windows AArch64 builds
 [v6]
In-Reply-To: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
Message-ID: <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>

> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.

Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailing whitespace
 - Simplify documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24267/files
  - new: https://git.openjdk.org/jdk/pull/24267/files/11e906be..5719a8f9

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

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

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

From naoto at openjdk.org  Wed Apr 16 16:17:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Apr 2025 16:17:49 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2810074157

From mikael at openjdk.org  Wed Apr 16 16:30:54 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 16 Apr 2025 16:30:54 GMT
Subject: RFR: 8351603: Change to GCC 14.2.0 for building on Linux at Oracle
 [v3]
In-Reply-To: <f5Io9l7IBn0pejyjNuO4j33spWO8OEfdmEAaZnX4SJ4=.8a84316e-475b-43fb-ae32-b0166a04b786@github.com>
References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com>
 <f5Io9l7IBn0pejyjNuO4j33spWO8OEfdmEAaZnX4SJ4=.8a84316e-475b-43fb-ae32-b0166a04b786@github.com>
Message-ID: <uemUguiehw-KkWnpMwkgkeBj9cWKWPyQ1jNoGPUUtN0=.80b8d121-5890-4357-9be3-49823f1bc716@github.com>

On Tue, 15 Apr 2025 16:04:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Background:
>> 
>> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0.
>> 
>> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed).
>> 
>> Testing:
>> 
>> Manual builds, tier1-5 + additional func & performance testing.
>
> Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8351603-gcc-14.2.0
>  - Update jib-profiles.js
>  - Update doc/building.{md,html}
>  - Add missing liblto_plugin.so link
>  - Change to GCC 14.2.0 for building on Linux at Oracle

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23975#issuecomment-2810103906

From mikael at openjdk.org  Wed Apr 16 16:30:54 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 16 Apr 2025 16:30:54 GMT
Subject: Integrated: 8351603: Change to GCC 14.2.0 for building on Linux at
 Oracle
In-Reply-To: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com>
References: <3ttjW_fokZpbAwiOc9w3lXBpR2gsT36N6mtb6GLkX2I=.a4430565-4ec6-48b1-9c7f-e8d0caa98f68@github.com>
Message-ID: <DO3C7L_XZG62gn6zYMKwBrmWGXSHqIE4CR4vvVP46E8=.be3e38cc-cda7-477d-8333-312939f3ef35@github.com>

On Mon, 10 Mar 2025 22:42:47 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Background:
> 
> Oracle is updating the version of GCC for building the JDK on Linux to 14.2.0.
> 
> This change updates the versions of the components used for the (Linux) devkit. Newer versions of ccache use cmake for the build, so some of the logic in `make/devkit/Tools.gmk` had to be updated to support cmake based components. This change also fixes JDK-8344272 (gcc devkit doesn't have lto-plugin where needed).
> 
> Testing:
> 
> Manual builds, tier1-5 + additional func & performance testing.

This pull request has now been integrated.

Changeset: 7a107e2f
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a107e2fc4b0ea5c6d82fd047a631aff37bf3e74
Stats:     45 lines in 4 files changed: 30 ins; 0 del; 15 mod

8351603: Change to GCC 14.2.0 for building on Linux at Oracle
8344272: gcc devkit doesn't have lto-plugin where needed

Reviewed-by: ihse, erikj

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

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

From erikj at openjdk.org  Wed Apr 16 17:12:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Apr 2025 17:12:57 GMT
Subject: RFR: 8353009: Improve documentation for Windows AArch64 builds
 [v6]
In-Reply-To: <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
Message-ID: <P5ukNnA0cgNwDlTpkAZN_HWx7nYlI8vsZ4_KfpUZip4=.2cdcf416-0279-486d-9b40-2ee14d659944@github.com>

On Wed, 16 Apr 2025 14:50:57 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Simplify documentation

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24267#pullrequestreview-2773261525

From duke at openjdk.org  Wed Apr 16 18:08:51 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 18:08:51 GMT
Subject: RFR: 8353009: Improve documentation for Windows AArch64 builds
 [v6]
In-Reply-To: <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
Message-ID: <CLx505x5hcwuagfH3h6q5OHT9xl4rtQAHr1T02Trpi4=.c0198800-9271-4abc-b4aa-4cf5791ab9cb@github.com>

On Wed, 16 Apr 2025 14:50:57 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Simplify documentation

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

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

PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2810333096

From clanger at openjdk.org  Wed Apr 16 18:25:38 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 16 Apr 2025 18:25:38 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public [v4]
In-Reply-To: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
References: <sOHFKbGMg5BxWi50PAlpvRQM1BT9umFJTCE0UBlmzIc=.755d86f0-3e10-4877-9dd3-328194b08c81@github.com>
Message-ID: <hVay8QPlSHsGScgLCfrUQANQYZtnarRZERjOxl997k0=.5ef43901-afdd-4868-af8e-e36b9487749b@github.com>

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Merge branch 'master' into JDK-8351842-alternative
 - Extract fix for building debug symbols bundle
 - JDK-8351842

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

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

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

From lmesnik at openjdk.org  Thu Apr 17 00:53:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Apr 2025 00:53:00 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
Message-ID: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>

Added problemlists and and requires for execution tests with --enable-preview.

The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 

The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

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

Commit messages:
 - 8353214: Add testing with --enable-preview

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

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

From mikael at openjdk.org  Thu Apr 17 04:30:18 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 17 Apr 2025 04:30:18 GMT
Subject: RFR: 8354902: Change to Visual Studio 17.13.2 for building on Windows
 at Oracle
Message-ID: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>

Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.

Testing: tier1-5

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

Commit messages:
 - 8354902: Change to Visual Studio 17.13.2 for building on Windows at Oracle

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

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

From liach at openjdk.org  Thu Apr 17 05:08:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 05:08:44 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: <xkk66RCghswR74Y2eHruwp6dEVdnmD5O_WRAlS-_hq8=.21d36435-d1e3-461d-9d67-78f47fc76788@github.com>

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

Just curious, which tiers have you run with forced `--enable-preview` and discovered such incompatible tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2811755132

From jwaters at openjdk.org  Thu Apr 17 07:35:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Apr 2025 07:35:12 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <TDS2yBKCtDF682ls-8ow6arf6A4ugEWiqHGe0mhoohA=.74e8ba57-9dcd-4835-8622-a608496bc765@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

Adding HotSpot mailing lists as I removed the rule for .c files in the .editorconfig since there should be no .c files in HotSpot

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

PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2812047339

From jwaters at openjdk.org  Thu Apr 17 07:35:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Apr 2025 07:35:12 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global .editorconfig
Message-ID: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>

The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

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

Commit messages:
 - Move HotSpot formatting rules to global .editorconfig
 - Delete src/hotspot/.editorconfig

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

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

From mbaesken at openjdk.org  Thu Apr 17 09:07:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 09:07:41 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
 <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
Message-ID: <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>

On Wed, 16 Apr 2025 10:40:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> make/autoconf/jdk-options.m4 line 526:
>> 
>>> 524:   UBSAN_LDFLAGS="$UBSAN_CHECKS"
>>> 525:   if test "x$TOOLCHAIN_TYPE" = "xclang" && test "x$OPENJDK_TARGET_OS" = "xaix"; then
>>> 526:       UBSAN_CFLAGS="$UBSAN_CFLAGS -fno-sanitize=function,vptr -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer"
>> 
>> I would recommend handling this tool path properly, by first trying to look it up with one of the standard macros and then falling back to a default, and let configure fail if it wasn't found. This would also implicitly add the ability for the user to specify a different path if ever needed (using VAR_NAME=/path/to/tool on the command line). However, since this isn't a platform I'm supporting, I won't force you.
>
> Can you please give me an example to try?

If the tool is (in case it is available) always at THIS position then it is not needed to add more logic.  On the other hand, what happens if it is not there ? Would we get just less complete stacks in case of ubsan issues?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2048549963

From jkern at openjdk.org  Thu Apr 17 09:22:50 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 17 Apr 2025 09:22:50 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
 <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
 <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>
Message-ID: <0s65QMMLNJGqqKHeKKto5zo7gYE5GrgRQ8xFIcJJ940=.b811976b-c55c-4ec3-a692-d3058d8478ef@github.com>

On Thu, 17 Apr 2025 09:05:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Can you please give me an example to try?
>
> If the tool is (in case it is available) always at THIS position then it is not needed to add more logic.  On the other hand, what happens if it is not there ? Would we get just less complete stacks in case of ubsan issues?

We would just get a stack without symbol resolution (not very helpful) and the ubsan message that the symbolizer could not be found.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2048574186

From mbaesken at openjdk.org  Thu Apr 17 10:31:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 10:31:49 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <0s65QMMLNJGqqKHeKKto5zo7gYE5GrgRQ8xFIcJJ940=.b811976b-c55c-4ec3-a692-d3058d8478ef@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
 <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
 <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>
 <0s65QMMLNJGqqKHeKKto5zo7gYE5GrgRQ8xFIcJJ940=.b811976b-c55c-4ec3-a692-d3058d8478ef@github.com>
Message-ID: <jnLEI6-11wiMgB5UBOtyclb-azaD8vdk755X0uLSRFk=.3df81d00-38b6-46d9-9342-c39a8e48c68d@github.com>

On Thu, 17 Apr 2025 09:20:23 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> If the tool is (in case it is available) always at THIS position then it is not needed to add more logic.  On the other hand, what happens if it is not there ? Would we get just less complete stacks in case of ubsan issues?
>
> We would just get a stack without symbol resolution (not very helpful) and the ubsan message that the symbolizer could not be found.

okay thanks.
So back to my first question - is the tool always at this position ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2048677436

From jkern at openjdk.org  Thu Apr 17 10:53:40 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 17 Apr 2025 10:53:40 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <jnLEI6-11wiMgB5UBOtyclb-azaD8vdk755X0uLSRFk=.3df81d00-38b6-46d9-9342-c39a8e48c68d@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
 <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
 <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>
 <0s65QMMLNJGqqKHeKKto5zo7gYE5GrgRQ8xFIcJJ940=.b811976b-c55c-4ec3-a692-d3058d8478ef@github.com>
 <jnLEI6-11wiMgB5UBOtyclb-azaD8vdk755X0uLSRFk=.3df81d00-38b6-46d9-9342-c39a8e48c68d@github.com>
Message-ID: <9n7fq3kKDzzlcTBwxyABS2wYtRIyc1GgBgBzIBMgl04=.f0803190-6ee7-41ab-8854-b8ab474f98d8@github.com>

On Thu, 17 Apr 2025 10:29:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We would just get a stack without symbol resolution (not very helpful) and the ubsan message that the symbolizer could not be found.
>
> okay thanks.
> So back to my first question - is the tool always at this position ?

For the 17.1.2 Compiler it is always at the same position relative to the compiler executable itself. Of course you can install the 17.1.2 Compiler at a different absolute place, but this does not break the relative position to the compiler executable.
I do not know if it is stored at the same relative position in future versions of the compiler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2048705792

From mbaesken at openjdk.org  Thu Apr 17 10:58:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 10:58:50 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <9n7fq3kKDzzlcTBwxyABS2wYtRIyc1GgBgBzIBMgl04=.f0803190-6ee7-41ab-8854-b8ab474f98d8@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <UcSBmeC1DK1yrsXwhC0i8QGHEHngVxubNXEJpdW0tmo=.b37cd848-dd1a-4fe3-a21f-8373b76b9044@github.com>
 <hmWqzHb7_NMAbuYusZ7_iofpoEKc2LGCnYACurpTGJg=.7e49e0c0-9ba3-40f9-a9e5-f2150664e003@github.com>
 <4-HvPWA23ioZamfYKjTxioa15d8WBt11qVFl2n3unTc=.21f303b4-4acf-43e6-aecc-14c7ebfe4905@github.com>
 <0s65QMMLNJGqqKHeKKto5zo7gYE5GrgRQ8xFIcJJ940=.b811976b-c55c-4ec3-a692-d3058d8478ef@github.com>
 <jnLEI6-11wiMgB5UBOtyclb-azaD8vdk755X0uLSRFk=.3df81d00-38b6-46d9-9342-c39a8e48c68d@github.com>
 <9n7fq3kKDzzlcTBwxyABS2wYtRIyc1GgBgBzIBMgl04=.f0803190-6ee7-41ab-8854-b8ab474f98d8@github.com>
Message-ID: <KWDonhcZdBgRAm23B2LdQ9WmYDkZWe52GfaX_KqAIBs=.12b16775-56bc-422f-82c8-c28b9915aeb4@github.com>

On Thu, 17 Apr 2025 10:51:25 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> okay thanks.
>> So back to my first question - is the tool always at this position ?
>
> For the 17.1.2 Compiler it is always at the same position relative to the compiler executable itself. Of course you can install the 17.1.2 Compiler at a different absolute place, but this does not break the relative position to the compiler executable.
> I do not know if it is stored at the same relative position in future versions of the compiler.

Thanks for clarifying!  For 17.1.1 the ubsan stuff does not work anyway.  For 17.1.2 it is the same (**relative**) position.  So I guess we can leave it as it is ;  in case XLC 18 or 19 has another tool or other fs layout of its binaries we have to deal with this anyway .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24667#discussion_r2048711742

From mbaesken at openjdk.org  Thu Apr 17 11:02:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 11:02:57 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible
In-Reply-To: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
Message-ID: <MaoGGzlCvkLIVbcmzJ4xve4xm6-vhgnLJ_iXpfZ8wUw=.0d04b3cf-911a-44d9-bf0d-0a60f51b526b@github.com>

On Tue, 15 Apr 2025 18:40:57 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
> Unfortunately there has to be some adoptions.
> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.

Please adjust COPYRIGHT header in ubsan_default_options.c.
And I think a comment line in the m4 and c file would not hurt.

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

PR Comment: https://git.openjdk.org/jdk/pull/24667#issuecomment-2812513067

From erikj at openjdk.org  Thu Apr 17 12:47:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Apr 2025 12:47:45 GMT
Subject: RFR: 8354902: Change to Visual Studio 17.13.2 for building on
 Windows at Oracle
In-Reply-To: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
References: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
Message-ID: <kERNnKKoYwz9DroQ4ursO-oRHvEzW2Khnu7N8p6QYnY=.5cbf146c-55a4-47e6-a07c-ac9702a166cf@github.com>

On Thu, 17 Apr 2025 01:17:50 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.
> 
> Testing: tier1-5

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24707#pullrequestreview-2775604808

From erikj at openjdk.org  Thu Apr 17 12:50:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Apr 2025 12:50:48 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: <DQ8UuSVbTC2KVNY3_6cNUfDpPdtbNQnMsnNoGiIql0Q=.6104faf0-9fb8-4fa6-a6bc-0f059693005b@github.com>

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24706#pullrequestreview-2775610558

From erikj at openjdk.org  Thu Apr 17 12:52:41 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Apr 2025 12:52:41 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <2nQ0Ar2RzLj6jQFbo6OhZ0h1tO9n98CxSmFAdUvqq1c=.7f1d4998-21ee-43b9-a534-2db81b10ca37@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

I think this is ok, but would like to hear from someone actually using this too.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24714#pullrequestreview-2775616208

From ihse at openjdk.org  Thu Apr 17 13:59:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 13:59:43 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <vSTuYTAtiUNrykVun3PY0g2AWLi60a7yVZXx0kAIIV4=.17a232a0-f611-448c-8c36-2eff218e1f12@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

`KEEPALIVE`

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2813019172

From duke at openjdk.org  Thu Apr 17 14:02:59 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Thu, 17 Apr 2025 14:02:59 GMT
Subject: Integrated: 8353009: Improve documentation for Windows AArch64 builds
In-Reply-To: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
Message-ID: <unrsq1l-S06hhNm-jBpbPFEikdmBLcwMDkDmowAd6Go=.155b9246-8217-44b1-a2ff-8fd9372d6a17@github.com>

On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.

This pull request has now been integrated.

Changeset: 86f3eafa
Author:    Saint Wesonga <saint.wesonga at microsoft.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86f3eafade20bd901b0657ab9ad1bdf12d1143c2
Stats:     32 lines in 2 files changed: 32 ins; 0 del; 0 mod

8353009: Improve documentation for Windows AArch64 builds

Reviewed-by: erikj, ihse

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

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

From ihse at openjdk.org  Thu Apr 17 14:02:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 14:02:59 GMT
Subject: RFR: 8353009: Improve documentation for Windows AArch64 builds
 [v6]
In-Reply-To: <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
References: <npQF7O4_IYT2ZqpxFmRIySPssWeF3eRBnurGEoyHwK8=.4d3835d4-557d-444a-9e85-5a8a820562f3@github.com>
 <gw0djlkZjqt87gtsRo7tH3PYgvTLYOozBgE1No8eoRA=.821d58eb-6c0a-4e23-bbe1-6a1a84943213@github.com>
Message-ID: <Aee8eEuaVls0ffxmDeG1DakGHKfR07nMEk3149rPpvA=.74c40b7c-cd70-48b4-81db-818904f2b968@github.com>

On Wed, 16 Apr 2025 14:50:57 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> The target selection configuration flag for Windows AArch64 should be added to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Simplify documentation

?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24267#pullrequestreview-2775843137

From ihse at openjdk.org  Thu Apr 17 14:04:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2025 14:04:59 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
Message-ID: <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>

On Wed, 16 Apr 2025 16:14:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)

Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README.

Is there some specific problem you are worried about on Windows that you were thinking about?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813033188

From mbaesken at openjdk.org  Thu Apr 17 14:05:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Apr 2025 14:05:01 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
Message-ID: <NgmRxKnVGTlVGFUk0mdoSQu4JefMvXt_l7JBXs1TDE8=.18e3c24f-3470-4dbd-a4bf-f9abb014910a@github.com>

On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim

Little additional info regarding AIX, when allowing  locale C in the basic.m4 too by patching your change , the build works nicely for me,  even on a AIX machine without  the C.UTF-8 or en_US.UTF-8 locales.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813037836

From jkern at openjdk.org  Thu Apr 17 15:42:09 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 17 Apr 2025 15:42:09 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible [v2]
In-Reply-To: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
Message-ID: <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>

> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
> Unfortunately there has to be some adoptions.
> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.

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

  adding comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24667/files
  - new: https://git.openjdk.org/jdk/pull/24667/files/ae22be6e..39a976f0

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

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

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

From naoto at openjdk.org  Thu Apr 17 16:29:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Apr 2025 16:29:56 GMT
Subject: RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
 <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
Message-ID: <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>

On Thu, 17 Apr 2025 14:01:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is there some specific problem you are worried about on Windows that you were thinking about?

I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2813487827

From rriggs at openjdk.org  Thu Apr 17 19:34:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Apr 2025 19:34:47 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <xkk66RCghswR74Y2eHruwp6dEVdnmD5O_WRAlS-_hq8=.21d36435-d1e3-461d-9d67-78f47fc76788@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
 <xkk66RCghswR74Y2eHruwp6dEVdnmD5O_WRAlS-_hq8=.21d36435-d1e3-461d-9d67-78f47fc76788@github.com>
Message-ID: <G1sRvjdiLfPpvgOwM9133WnraISAqbKNfGND6PXCvuI=.a7ae073f-41a5-4a4e-8018-262d3f19814e@github.com>

On Thu, 17 Apr 2025 05:06:24 GMT, Chen Liang <liach at openjdk.org> wrote:

> Just curious, which tiers have you run with forced `--enable-preview` and discovered such incompatible tests?

I've run tiers 1-3 and have not found any incompatible tests (by that means).

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

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2813847009

From lmesnik at openjdk.org  Thu Apr 17 20:10:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 17 Apr 2025 20:10:52 GMT
Subject: RFR: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: <KkMB5GP-wJgLew7lww__-WmiVf_60XrqfyUmAcgzY6Y=.a7799e15-1cbb-4acb-a8f5-311cfc341e30@github.com>

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

A couple of failures were in tier1 and one in tier4 hotspot testing (nsk/jdi one)

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

PR Comment: https://git.openjdk.org/jdk/pull/24706#issuecomment-2813914722

From kvn at openjdk.org  Thu Apr 17 20:37:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 17 Apr 2025 20:37:08 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache
Message-ID: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>

[JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.

We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.

Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):


(perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
         0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )

(perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
         0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )


New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):


-XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
-XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
-XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure

By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
Specifying this flag without using `AOTCache` will cause error during VM initialization:


java -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -cp hello.jar HelloWorld
Error occurred during initialization of VM
AOTCache must be specified when using AOT code caching


To use AOT adapters follow process described in JEP 483:


java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
java -XX:AOTCache=app.aot -cp app.jar App


There are several new UL flag combinations to trace the AOT code caching process:


-Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs


@ashu-mehra is main author of changes. He implemented adapters caching.
I did main framework (`AOTCodeCache` class) for saving and loading AOT code.

Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

Commit messages:
 - 8350209: Preserve adapters in AOT cache

Changes: https://git.openjdk.org/jdk/pull/24740/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350209
  Stats: 3148 lines in 46 files changed: 2679 ins; 200 del; 269 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

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

From liach at openjdk.org  Thu Apr 17 20:45:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 20:45:04 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
Message-ID: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>

Perf numbers for simple main:
Linking of `Class::forName0` down from ~152 to ~83

For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
JNI: ~45
baseline panama: ~164
patch: ~103

Also see #24705.

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

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Wip work trying to speed up FFM

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

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

From liach at openjdk.org  Fri Apr 18 03:39:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 03:39:44 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: <_8oIoaRrodstOsLcs6BGkHH5zdTEkxeJvoIRRouJ0fM=.42bf4092-196c-40e1-935d-cf6c12b04b85@github.com>

On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

Testing: tier 1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/24742#issuecomment-2814458553

From asmehra at openjdk.org  Fri Apr 18 06:05:00 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 18 Apr 2025 06:05:00 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <j-qfgpm4RCsm_YJaSy5AZy6BK3uQXSisMn6BaU-zIP0=.55485425-276b-45b5-95e4-fe8e32504790@github.com>

On Thu, 17 Apr 2025 19:11:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> Specifying this flag without using `AOTCache` will cause error during VM initialization:
> 
> 
> java -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -cp hello.jar HelloWorld
> Error occurred during initialization of VM
> AOTCache must be specified when using AOT code caching
> 
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

@vnkozlov I forgot to remove `AOTCodeSection` from `code/aotCodeCache.hpp` when I refactored the APIs. This struct is no longer used. Can you please remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2814619954

From kvn at openjdk.org  Fri Apr 18 14:14:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 18 Apr 2025 14:14:46 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v2]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <unCf0nVO9jne3IHnaqp0x_7DQeau4L8wQ_cAUcY1zCg=.38a1024c-b18c-4efd-a0e2-5f0bea9c3308@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> Specifying this flag without using `AOTCache` will cause error during VM initialization:
> 
> 
> java -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -cp hello.jar HelloWorld
> Error occurred during initialization of VM
> AOTCache must be specified when using AOT code caching
> 
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  Removed unused AOTCodeSection class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/544a4aa8..43517ebf

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

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

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

From kvn at openjdk.org  Fri Apr 18 14:14:47 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 18 Apr 2025 14:14:47 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache
In-Reply-To: <j-qfgpm4RCsm_YJaSy5AZy6BK3uQXSisMn6BaU-zIP0=.55485425-276b-45b5-95e4-fe8e32504790@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <j-qfgpm4RCsm_YJaSy5AZy6BK3uQXSisMn6BaU-zIP0=.55485425-276b-45b5-95e4-fe8e32504790@github.com>
Message-ID: <rxqz7QLtHPppjWKKI3ptgOIrdJ4wFVI7e7_qKjJEUsE=.2f33fa9d-061a-4b77-bfff-d286b91e63ed@github.com>

On Fri, 18 Apr 2025 06:01:43 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> @vnkozlov I forgot to remove `AOTCodeSection` from `code/aotCodeCache.hpp` when I refactored the APIs. This struct is no longer used. Can you please remove it.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2815526181

From jvernee at openjdk.org  Fri Apr 18 17:52:45 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 17:52:45 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: <Ti-G8P-NImbeCdmSVKCZhYj-KGhQlIRMIv0at0DYCYg=.ce8769c6-6b17-404c-ac75-5dd455e7cede@github.com>

On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:

> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
> 189:         Optional<MemorySegment> symbol = lookup.find("Java_java_lang_Class_forName0");
> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);

FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050929830

From liach at openjdk.org  Fri Apr 18 17:59:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 17:59:59 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <Ti-G8P-NImbeCdmSVKCZhYj-KGhQlIRMIv0at0DYCYg=.ce8769c6-6b17-404c-ac75-5dd455e7cede@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Ti-G8P-NImbeCdmSVKCZhYj-KGhQlIRMIv0at0DYCYg=.ce8769c6-6b17-404c-ac75-5dd455e7cede@github.com>
Message-ID: <M-jStrG3lLmenJp-_lO8b37z62KF4x7H7jK3Jeh05Ec=.3ca81f24-e15c-4660-a260-b77c94b44e8b@github.com>

On Fri, 18 Apr 2025 17:49:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:
> 
>> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>> 189:         Optional<MemorySegment> symbol = lookup.find("Java_java_lang_Class_forName0");
>> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);
> 
> FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.

So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050937126

From kvn at openjdk.org  Fri Apr 18 18:10:22 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 18 Apr 2025 18:10:22 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v3]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <Aj4Vy9dW3jzlzBOwQkcs_e3eWLlgBB71KbH5Nxj9KRI=.f9ad8e8a-85a9-4e66-b54a-92c1706cfcb5@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> Specifying this flag without using `AOTCache` will cause error during VM initialization:
> 
> 
> java -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -cp hello.jar HelloWorld
> Error occurred during initialization of VM
> AOTCache must be specified when using AOT code caching
> 
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/43517ebf..ed37319b

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

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

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

From jvernee at openjdk.org  Fri Apr 18 18:17:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Apr 2025 18:17:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
In-Reply-To: <M-jStrG3lLmenJp-_lO8b37z62KF4x7H7jK3Jeh05Ec=.3ca81f24-e15c-4660-a260-b77c94b44e8b@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Ti-G8P-NImbeCdmSVKCZhYj-KGhQlIRMIv0at0DYCYg=.ce8769c6-6b17-404c-ac75-5dd455e7cede@github.com>
 <M-jStrG3lLmenJp-_lO8b37z62KF4x7H7jK3Jeh05Ec=.3ca81f24-e15c-4660-a260-b77c94b44e8b@github.com>
Message-ID: <P72ngpDjb52FwlhdIRuSqH-TPI_qrlEqQRO4O2K_TBE=.1a032652-4e63-48b4-bc20-fe4bbb04c175@github.com>

On Fri, 18 Apr 2025 17:56:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190:
>> 
>>> 188:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>>> 189:         Optional<MemorySegment> symbol = lookup.find("Java_java_lang_Class_forName0");
>>> 190:         var _ = linker.downcallHandle(symbol.orElseThrow(), signature);
>> 
>> FWIW, passing just the signature should result in mostly the same code being generated. The address is just attached using MethodHandles::insertArguments.
>
> So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?

Yes, that would work, but I was thinking just `Linker.nativeLinker().downcallHandle(signature)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050958874

From liach at openjdk.org  Fri Apr 18 18:25:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 18:25:54 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

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

  Simplify FFM linker warmup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24742/files
  - new: https://git.openjdk.org/jdk/pull/24742/files/f9a0533f..dbf7799c

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

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

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

From liach at openjdk.org  Fri Apr 18 18:35:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Apr 2025 18:35:40 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <P72ngpDjb52FwlhdIRuSqH-TPI_qrlEqQRO4O2K_TBE=.1a032652-4e63-48b4-bc20-fe4bbb04c175@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Ti-G8P-NImbeCdmSVKCZhYj-KGhQlIRMIv0at0DYCYg=.ce8769c6-6b17-404c-ac75-5dd455e7cede@github.com>
 <M-jStrG3lLmenJp-_lO8b37z62KF4x7H7jK3Jeh05Ec=.3ca81f24-e15c-4660-a260-b77c94b44e8b@github.com>
 <P72ngpDjb52FwlhdIRuSqH-TPI_qrlEqQRO4O2K_TBE=.1a032652-4e63-48b4-bc20-fe4bbb04c175@github.com>
Message-ID: <Ez6oZhleCx70BzOhTlKTm315IsVp8C2X8IQD2ITqTro=.7f7a0c46-512d-4cf7-9156-4553a55ddaab@github.com>

On Fri, 18 Apr 2025 18:15:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new byte[0]), signature)` suffices?
>
> Yes, that would work, but I was thinking just `Linker.nativeLinker().downcallHandle(signature)`

Yep, simplified this, the startup results are still similar.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2050975328

From kvn at openjdk.org  Fri Apr 18 18:45:24 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 18 Apr 2025 18:45:24 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v4]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <ow5fMXwkE6XVWskKG7qJKiFVcI8VAvpBjnk5ggI0Kq0=.bd205b2d-5d47-4d5e-aba9-c6ff6e7a3bc2@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  Add sanity test for AOTAdapterCaching flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/ed37319b..2863a964

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

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

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

From syan at openjdk.org  Sun Apr 20 03:55:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 03:55:46 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
Message-ID: <Wpd0sg8kbty1KKj4zbd-BzHEVOkm_Nu95OvO6OYm9QY=.19c91de6-2ada-405e-8aef-2e3447e4060c@github.com>

On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

Should we update the copyright year from 2024 to 2025 for make/autoconf/spec.gmk.template file

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

Changes requested by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24481#pullrequestreview-2780139417

From syan at openjdk.org  Sun Apr 20 04:05:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Apr 2025 04:05:43 GMT
Subject: RFR: 8345874: Run make doctor automatically on failed CI builds
 [v2]
In-Reply-To: <aP_O9sjC7Z4SKP926eonLrqLRHc49tzkwhKBvhAqdrs=.ac8da7ea-e2d2-41c8-b9de-c3923ab1e518@github.com>
References: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>
 <aP_O9sjC7Z4SKP926eonLrqLRHc49tzkwhKBvhAqdrs=.ac8da7ea-e2d2-41c8-b9de-c3923ab1e518@github.com>
Message-ID: <n_0zgeGsd28f8aBPJhiIlTyXy3P0grCxiJrhDP6sP5A=.4696f43c-7bc4-426d-b8d4-7eb5f47ceef8@github.com>

On Wed, 9 Apr 2025 20:29:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> If there is something wrong with the build, the user can run "make doctor". That is hard to do in a CI setting. Instead, if the build environment is detected to be a CI, we should run the doctor automatically in case of a failed build.
>
> 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 two commits:
> 
>  - Merge branch 'master' into make-doctor-on-ci
>  - 8345874: Run make doctor automatically on failed CI builds

make/autoconf/spec.gmk.template line 173:

> 171: 
> 172: # dev or ci
> 173: BUILD_ENV := @BUILD_ENV@

I think the `BUILD_ENV` could be seted in command line also. So, should we update the doc/building.md sync with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24485#discussion_r2051629135

From jwaters at openjdk.org  Sun Apr 20 12:24:40 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 20 Apr 2025 12:24:40 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <LkypoBb6kcK610UvEBCeDBFkiLjzn7Ze74RODBOxQJc=.4aed3321-5d0e-4c79-b8cc-f4094133b560@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

Currently awaiting review from HotSpot Reviewers as to whether the removal of .c file matching for HotSpot is reasonable or not

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

PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2817145939

From liach at openjdk.org  Sun Apr 20 23:49:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 20 Apr 2025 23:49:44 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <yc4_YLvLkiTS6jBG2JsA4N-MdbOFxuypvyTGEcZH5BE=.4d211540-82a0-4c97-8595-e037d771b70b@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

I think the original hotspot location may be fine - each subject area has its own styles. For example, in jdk.hotspot.agent, even c and java source files have indentation of 2 spaces, unlike those in java.base.

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

PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2817392684

From serb at openjdk.org  Mon Apr 21 06:58:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 21 Apr 2025 06:58:46 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
Message-ID: <fIoGiwqwll0fEMH2tPu1fMnYdVVtBlUPD28wLeuCMZg=.b784cb02-64f1-4209-8422-b1c7abf980ba@github.com>

On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

It might be helpful to clarify which combinations of JCOV, ASM, Javatest, and TestNG are currently supported. For example, the JCOV repository still references [ASM 9.7.1](https://github.com/openjdk/jcov/blob/29e9fdf06ef195f25c121b5069e2292d48bcbeb5/build/build.properties#L33), which appears to be outdated and incompatible with JDK 25.

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

PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2817786647

From serb at openjdk.org  Mon Apr 21 07:01:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 21 Apr 2025 07:01:49 GMT
Subject: RFR: 8282493: Add --with-jcov-modules convenience option
In-Reply-To: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
References: <ztIzfhlAgtvkYBktnccvM_0Y4nZF-ZerLwBAcl02l4s=.832b1476-a242-436a-bb17-34660cc36fc9@github.com>
Message-ID: <6VO4wnIDI5lPu7wdEEnVRAE5QDi-3FsUQKUzYS0fneI=.6f97586f-2c15-4e2e-8adf-863ca6c38aea@github.com>

On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering.

Description of the new option can be added to [testing.md](https://github.com/openjdk/jdk/blob/128f2d1cadae3cf91e4c590e6dabe2086737b7dd/doc/testing.md?plain=1#L339).

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

PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2817790547

From jwaters at openjdk.org  Tue Apr 22 01:23:44 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Apr 2025 01:23:44 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <yc4_YLvLkiTS6jBG2JsA4N-MdbOFxuypvyTGEcZH5BE=.4d211540-82a0-4c97-8595-e037d771b70b@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
 <yc4_YLvLkiTS6jBG2JsA4N-MdbOFxuypvyTGEcZH5BE=.4d211540-82a0-4c97-8595-e037d771b70b@github.com>
Message-ID: <ND8t8SibvTNzXhGB00GXzMJdbD_BXtHqn9JIFmFrbFs=.6539b479-8ad7-4070-8327-c79fed481ea1@github.com>

On Sun, 20 Apr 2025 23:47:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think the original hotspot location may be fine - each subject area has its own styles. For example, in jdk.hotspot.agent, even c and java source files have indentation of 2 spaces, unlike those in java.base.

Ideally we'd just have one .editorconfig and override the styles for the source code of each module in that root .editorconfig rather than sprinkling .editorconfigs across each directory where an override is desired, that seems cleaner to me at least

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

PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2819822044

From duke at openjdk.org  Tue Apr 22 07:33:14 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Tue, 22 Apr 2025 07:33:14 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
Message-ID: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>

After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.

The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.

Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
Note: In my environment, it worked correctly even without these options.

The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:

- `environment.html`: `windows/system/os` section
- `process.html`: `[Process ID]/windows/native/info` section

**Testing:**
I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.

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

Commit messages:
 - Use powershell instead of wmic

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

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

From duke at openjdk.org  Tue Apr 22 07:41:43 2025
From: duke at openjdk.org (Daishi Tabata)
Date: Tue, 22 Apr 2025 07:41:43 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
Message-ID: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>

> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
> 
> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
> 
> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
> Note: In my environment, it worked correctly even without these options.
> 
> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
> 
> - `environment.html`: `windows/system/os` section
> - `process.html`: `[Process ID]/windows/native/info` section
> 
> **Testing:**
> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.

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

  run jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24791/files
  - new: https://git.openjdk.org/jdk/pull/24791/files/36e466d2..76a3a7ee

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

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

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

From vklang at openjdk.org  Tue Apr 22 08:07:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 22 Apr 2025 08:07:55 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
Message-ID: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:

> 76:         @Override
> 77:         public boolean equals(Object obj) {
> 78:             return obj instanceof LinkRequest other &&

Might be worth checking `obj == this || obj instanceof ...`

src/java.base/share/classes/jdk/internal/foreign/abi/LinkerOptions.java line 149:

> 147:         @Override
> 148:         public boolean equals(Object obj) {
> 149:             return obj instanceof FirstVariadicArg that && index == that.index;

Might be worth checking `obj == this || obj instanceof ...`

src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 56:

> 54:         public boolean equals(Object o) {
> 55:             if (!(o instanceof CacheKey other)) return false;
> 56: 

Might be worth checking `o == this`

src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java line 55:

> 53:     @Override
> 54:     public boolean equals(Object obj) {
> 55:         return obj instanceof VMStorage that &&

Might be worth checking `obj == this || obj instanceof ...`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053566427
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053566702
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053569651
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2053568877

From liach at openjdk.org  Tue Apr 22 14:57:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 14:57:48 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
 <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
Message-ID: <Z2iQncxogKDPDW5oQ4yooD8CMqTSkzgBkOPsX3T880I=.37ead18f-c147-4762-a7db-848d289e98dc@github.com>

On Tue, 22 Apr 2025 08:03:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:
> 
>> 76:         @Override
>> 77:         public boolean equals(Object obj) {
>> 78:             return obj instanceof LinkRequest other &&
> 
> Might be worth checking `obj == this || obj instanceof ...`

No. We are always using `new LinkRequest` so this "fast path" will 100% miss.

> src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 56:
> 
>> 54:         public boolean equals(Object o) {
>> 55:             if (!(o instanceof CacheKey other)) return false;
>> 56: 
> 
> Might be worth checking `o == this`

Always used with `new CacheKey` in `NativeEntryPoint.make`, no benefit too.

> src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java line 55:
> 
>> 53:     @Override
>> 54:     public boolean equals(Object obj) {
>> 55:         return obj instanceof VMStorage that &&
> 
> Might be worth checking `obj == this || obj instanceof ...`

This one seems created each time when a particular downcall function shape is requested too; so no point of identity checks either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054294141
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054300716
PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054299075

From liach at openjdk.org  Tue Apr 22 15:00:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:00:41 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
 <6iGkzxPk3SpjQkYebGfrlU5bMM8k8UuHtkSiaoh_5qc=.50de17d4-238a-4374-a59d-dbe915af3e28@github.com>
Message-ID: <hLj6MQDvgooMxpb9B6l_0Ydo2pbl3sAyHSTaD1r4M0I=.671ac3ee-aa84-4993-9d9b-45c36112ebc7@github.com>

On Tue, 22 Apr 2025 08:03:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/LinkerOptions.java line 149:
> 
>> 147:         @Override
>> 148:         public boolean equals(Object obj) {
>> 149:             return obj instanceof FirstVariadicArg that && index == that.index;
> 
> Might be worth checking `obj == this || obj instanceof ...`

I think this is still unlikely to hit (it is possible if people intentionally reuse the value of a `Linker.Option.firstVariadicArg` call), most of the usages will see non-identity equality comparisons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2054306216

From mikael at openjdk.org  Tue Apr 22 15:59:04 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 22 Apr 2025 15:59:04 GMT
Subject: RFR: 8355235: Clean out old versions from Tools.gmk
Message-ID: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>

Traditionally, when upgrading the versions of the components (gcc, binutils, etc.) in Tools.gmk, the old versions/definitions have been preserved. The list is now starting to be on the long side, it's unlikely that anybody would be using anything but the latest/default version, and if they do it is possible to get it from the source/version history.

Let's clean out the old version information, leaving only the latest/default.

Testing: tier1, manually built devkits for `x86_64-linux-gnu-to-{x86_64,aarch64,ppc64le,riscv64,s390x}-linux-gnu` and then built the JDK using those devkits.

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

Commit messages:
 - 8355235: Clean out old versions from Tools.gmk

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

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

From iklam at openjdk.org  Tue Apr 22 17:03:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Apr 2025 17:03:45 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v4]
In-Reply-To: <ow5fMXwkE6XVWskKG7qJKiFVcI8VAvpBjnk5ggI0Kq0=.bd205b2d-5d47-4d5e-aba9-c6ff6e7a3bc2@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ow5fMXwkE6XVWskKG7qJKiFVcI8VAvpBjnk5ggI0Kq0=.bd205b2d-5d47-4d5e-aba9-c6ff6e7a3bc2@github.com>
Message-ID: <6yy0-CK4wUWgLd23lWP6Z2crB4lMICXohP-NEw0YPok=.8b184803-d9d0-490d-9a27-0d9098f36888@github.com>

On Fri, 18 Apr 2025 18:45:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add sanity test for AOTAdapterCaching flag

src/hotspot/share/cds/cdsConfig.cpp line 869:

> 867: 
> 868: bool CDSConfig::is_dumping_aot_code_enabled() {
> 869:   return _is_dumping_aot_code_enabled;

Other functions in CDSConfig don't have the `_enabled()` suffix. E.g., `is_dumping_method_handles()`. It doesn't mean we are doing method handle right now, but rather we have the ability to do so.

Since we rarely ask "am I in the middle of dumping X right now", I think adding `_enabled()` will be redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2054507687

From kvn at openjdk.org  Tue Apr 22 17:28:12 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Apr 2025 17:28:12 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v4]
In-Reply-To: <6yy0-CK4wUWgLd23lWP6Z2crB4lMICXohP-NEw0YPok=.8b184803-d9d0-490d-9a27-0d9098f36888@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ow5fMXwkE6XVWskKG7qJKiFVcI8VAvpBjnk5ggI0Kq0=.bd205b2d-5d47-4d5e-aba9-c6ff6e7a3bc2@github.com>
 <6yy0-CK4wUWgLd23lWP6Z2crB4lMICXohP-NEw0YPok=.8b184803-d9d0-490d-9a27-0d9098f36888@github.com>
Message-ID: <SZpAlMUin3MNvAjOfCtKmu6F3L8u5gAa54bkwEuERQI=.2936b6ea-e3b6-42fb-a782-589c80ea061e@github.com>

On Tue, 22 Apr 2025 17:01:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add sanity test for AOTAdapterCaching flag
>
> src/hotspot/share/cds/cdsConfig.cpp line 869:
> 
>> 867: 
>> 868: bool CDSConfig::is_dumping_aot_code_enabled() {
>> 869:   return _is_dumping_aot_code_enabled;
> 
> Other functions in CDSConfig don't have the `_enabled()` suffix. E.g., `is_dumping_method_handles()`. It doesn't mean we are doing method handle right now, but rather we have the ability to do so.
> 
> Since we rarely ask "am I in the middle of dumping X right now", I think adding `_enabled()` will be redundant.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2054541461

From kvn at openjdk.org  Tue Apr 22 17:33:50 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Apr 2025 17:33:50 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v5]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <RYQlz2v-RpdGQ0SMBnn_Ki3I6s896caxdg3KiiWxPuA=.1fb53340-91b0-4686-b28f-a297cbd97dd6@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  remove _enabled suffix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/2863a964..ba08626b

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

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

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

From jiangli at openjdk.org  Tue Apr 22 21:14:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 21:14:16 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK
Message-ID: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>

Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.

`NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.

In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

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

Commit messages:
 - Use NativeLibraries.loadLibrary() to get the libsyslookup. This works on both regular and static JDK.

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

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

From liach at openjdk.org  Tue Apr 22 21:35:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 21:35:44 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK
In-Reply-To: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
Message-ID: <jyPrzI1OWFjry2KWMvIgoC89Z8jKFX8etExwzTpwZFk=.a33e3969-426d-409d-b8c1-48b093faf534@github.com>

On Tue, 22 Apr 2025 21:08:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

`sysLookup` does look much cleaner compared to `jdkLibraryPath`.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     @SuppressWarnings("restricted")
> 134:     private static SymbolLookup sysLookup() {
> 135:         NativeLibraries libs = jdk.internal.loader.NativeLibraries.newInstance(null);

Suggestion:

        NativeLibraries libs = NativeLibraries.newInstance(null);

We already imported this class.

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

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2785431747
PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2054915197

From kvn at openjdk.org  Tue Apr 22 22:42:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Apr 2025 22:42:08 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v6]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <vvtv6V1NJaSiW_Ey-NKDH1d0qLXkVBFo-DN84jZzw_k=.449a58c2-7a3e-4c02-a704-35508f720741@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  Generate far jumps for AOT code on AArch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/ba08626b..32b997d7

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

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

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

From kvn at openjdk.org  Tue Apr 22 22:45:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Apr 2025 22:45:41 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v6]
In-Reply-To: <vvtv6V1NJaSiW_Ey-NKDH1d0qLXkVBFo-DN84jZzw_k=.449a58c2-7a3e-4c02-a704-35508f720741@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <vvtv6V1NJaSiW_Ey-NKDH1d0qLXkVBFo-DN84jZzw_k=.449a58c2-7a3e-4c02-a704-35508f720741@github.com>
Message-ID: <wjgOPOV2yoUH2hrRbEDkOVdxO3QqgEOb2rlUQ6CrajU=.b631b1a7-d0c5-4800-9924-b4e66e9712f1@github.com>

On Tue, 22 Apr 2025 22:42:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Generate far jumps for AOT code on AArch64

Added missing changes for Aarch64 to always generate far jumps in AOT code. `generate_i2c2i_adapters()` use `far_jump()`.
Note, for x64 `ForceUnreachable` flag is set to `true` in `AOTCodeCache::initialize()`. Unfortunately Aarch64 does not use this flag, so I need to add check to each query functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2822631594

From kvn at openjdk.org  Tue Apr 22 23:05:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Apr 2025 23:05:13 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  Fix message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/32b997d7..91c37dad

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

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

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

From jiangli at openjdk.org  Tue Apr 22 23:29:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 23:29:02 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
Message-ID: <sQGrcMenHqkQq_W5EIM2g4dayT1egF8lXiO_mlR3IOA=.fbc1b90b-14d8-469f-b42a-81794a5e4329@github.com>

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

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

  Update src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java
  
  Thanks.
  
  I used `jdk.internal.loader.NativeLibraries` as a quick change before adding adding import. I neglected to to clean up that part.
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24801/files
  - new: https://git.openjdk.org/jdk/pull/24801/files/7cc1b268..11f674c6

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

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

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

From jiangli at openjdk.org  Tue Apr 22 23:29:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 22 Apr 2025 23:29:02 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: <jyPrzI1OWFjry2KWMvIgoC89Z8jKFX8etExwzTpwZFk=.a33e3969-426d-409d-b8c1-48b093faf534@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <jyPrzI1OWFjry2KWMvIgoC89Z8jKFX8etExwzTpwZFk=.a33e3969-426d-409d-b8c1-48b093faf534@github.com>
Message-ID: <jAX2ZpEtGrLUXZa1cZKdRMk2EVTK5eivPV0SNteWZpQ=.e0507898-9e6f-4cd0-817b-c23adbefbc0d@github.com>

On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> `sysLookup` does look much cleaner compared to `jdkLibraryPath`.

@liach Thanks for the quick review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2822696068

From henryjen at openjdk.org  Wed Apr 23 00:27:42 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 23 Apr 2025 00:27:42 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: <sQGrcMenHqkQq_W5EIM2g4dayT1egF8lXiO_mlR3IOA=.fbc1b90b-14d8-469f-b42a-81794a5e4329@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <sQGrcMenHqkQq_W5EIM2g4dayT1egF8lXiO_mlR3IOA=.fbc1b90b-14d8-469f-b42a-81794a5e4329@github.com>
Message-ID: <IHXSXBq5U0Q4O83e2ayBsDnbsNAsq_wZMuS53T8-t_c=.a507b53b-5120-4925-9754-2d95496a7483@github.com>

On Tue, 22 Apr 2025 23:29:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java
>   
>   Thanks.
>   
>   I used `jdk.internal.loader.NativeLibraries` as a quick change before adding adding import. I neglected to to clean up that part.
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

src/java.base/share/native/libsyslookup/syslookup.c line 30:

> 28: #include <stdlib.h>
> 29: 
> 30: #include <jni.h>

Do we need this include? DEF_STATIC_JNI_OnLoad is defined by jni_util.h, which should include jni.h?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2055074496

From duke at openjdk.org  Wed Apr 23 00:44:00 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Apr 2025 00:44:00 GMT
Subject: Withdrawn: 8346987: [lto] gtest build fails
In-Reply-To: <uXqt6XqvXe6N1jdUm4xR3MoIjibkBUip9mKKn4LnRwc=.7edf5a95-aaf9-4536-bc85-5ebfde400465@github.com>
References: <uXqt6XqvXe6N1jdUm4xR3MoIjibkBUip9mKKn4LnRwc=.7edf5a95-aaf9-4536-bc85-5ebfde400465@github.com>
Message-ID: <xoBkwipi8RtpWflKX5nfvJqJQuUVIU_bwGtKiExXlfc=.37947d40-c27f-4afd-8549-c5de37109c80@github.com>

On Fri, 17 Jan 2025 11:41:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building with link time optimization (lto) , configure flag is --enable-jvm-feature-link-time-opt , we run in the gtest build into a lot of errors.
> One workaround is just to configure without gtest ; this one changes the make to NOT use the lto build flags for gtest , just for the "normal" libjvm.so .

This pull request has been closed without being integrated.

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

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

From jiangli at openjdk.org  Wed Apr 23 00:56:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 00:56:18 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
Message-ID: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
 - Address henryjen@ comment:
   - Remove '#include <jni.h>'.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24801/files
  - new: https://git.openjdk.org/jdk/pull/24801/files/11f674c6..6661b815

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

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

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

From jiangli at openjdk.org  Wed Apr 23 00:56:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Apr 2025 00:56:18 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v2]
In-Reply-To: <IHXSXBq5U0Q4O83e2ayBsDnbsNAsq_wZMuS53T8-t_c=.a507b53b-5120-4925-9754-2d95496a7483@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <sQGrcMenHqkQq_W5EIM2g4dayT1egF8lXiO_mlR3IOA=.fbc1b90b-14d8-469f-b42a-81794a5e4329@github.com>
 <IHXSXBq5U0Q4O83e2ayBsDnbsNAsq_wZMuS53T8-t_c=.a507b53b-5120-4925-9754-2d95496a7483@github.com>
Message-ID: <Gs_L7P7KYUAfn_6fxQFMhHxLxj7-94aGdVTpM0N-nhY=.ba91f0c7-f620-49b5-b5b3-5fe1b1217f27@github.com>

On Wed, 23 Apr 2025 00:24:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Do we need this include? DEF_STATIC_JNI_OnLoad is defined by jni_util.h, which should include jni.h?

Removed, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2055090726

From liach at openjdk.org  Wed Apr 23 03:22:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 03:22:52 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v4]
In-Reply-To: <qjrKrdlFFACyU8RzAnukvjhB_Le4zerLkF7hubd-kZQ=.f2a5a196-4588-4452-8784-023a27922e29@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <qjrKrdlFFACyU8RzAnukvjhB_Le4zerLkF7hubd-kZQ=.f2a5a196-4588-4452-8784-023a27922e29@github.com>
Message-ID: <0hSBVgWTTcbmEF1OQVVptjzsahPiyRNkQi1cbpLuTC8=.ee19f511-c795-48ee-8bf3-0d4987934d23@github.com>

On Wed, 16 Apr 2025 12:07:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback: Adding makefile comment as suggested

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 175:

> 173:     protected final Charset charset;
> 174:     protected final Object readLock;
> 175:     protected final Object writeLock;

Recommend mentioning that when both locks must be acquired, the `writeLock` must be acquired first. Unfortunately we cannot just use a `ReentrantReadWriteLock`.

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 181:

> 179:     protected final Formatter formatter;
> 180: 
> 181:     protected abstract char[] readline(boolean password) throws IOException;

I recommend a more distinct method name, like `nextLine` or `implReadLine`; using `readline` to distinguish from `readLine` is weird.

src/java.base/share/classes/jdk/internal/io/BaseJdkConsoleImpl.java line 184:

> 182: 
> 183:     @SuppressWarnings("this-escape")
> 184:     public BaseJdkConsoleImpl(Charset charset) {

Suggestion:

    protected BaseJdkConsoleImpl(Charset charset) {

src/jdk.internal.le/share/classes/jdk/internal/console/JdkConsoleImpl.java line 38:

> 36:  * JdkConsole implementation based on the platform's TTY, with basic keyboard navigation.
> 37:  */
> 38: public final class JdkConsoleImpl extends BaseJdkConsoleImpl {

We should choose a different simple name for this class, especially when we are importing classes from `jdk.internal.io` package.

src/jdk.internal.le/share/classes/jdk/internal/console/JdkConsoleImpl.java line 57:

> 55:     }
> 56: 
> 57:     protected char[] readline(boolean password) throws IOException {

`@Override`

src/jdk.internal.le/share/classes/jdk/internal/console/LastErrorException.java line 28:

> 26: 
> 27: @SuppressWarnings("serial")
> 28: public class LastErrorException extends RuntimeException{

Suggestion:

public class LastErrorException extends RuntimeException {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055177151
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055179038
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055177261
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055183690
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055181215
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2055181573

From liach at openjdk.org  Wed Apr 23 05:50:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 05:50:57 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <QgnTsf1flIRJwuqm12-8Lc1F79zQ015J7kHv34-r77M=.2a961810-6132-4668-a63c-daf50a4eba27@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

The rendered output and Java code change looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24417#pullrequestreview-2786001471

From duke at openjdk.org  Wed Apr 23 13:25:30 2025
From: duke at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 23 Apr 2025 13:25:30 GMT
Subject: RFR: 8355400: Better git detection in update_copyright_year.sh
Message-ID: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>

The script `make/scripts/update_copyright.sh` relies on the path to the script for git detection, which is fragile or does not work at all or git worktrees. This PR uses git itself to detect whether the script is running in a git repository. This has the added benefit that the script can be executed from anywhere in the repository.

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

Commit messages:
 - Better git detection

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

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

From erikj at openjdk.org  Wed Apr 23 14:23:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Apr 2025 14:23:43 GMT
Subject: RFR: 8355235: Clean out old versions from Tools.gmk
In-Reply-To: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
References: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
Message-ID: <H6rIFJujRhc2G7ZS_YDOPt3Aw-wCLsD3zM6CNr3KFI4=.7f1b87c9-0283-4e68-8afc-8085a39e58f7@github.com>

On Mon, 21 Apr 2025 22:51:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Traditionally, when upgrading the versions of the components (gcc, binutils, etc.) in Tools.gmk, the old versions/definitions have been preserved. The list is now starting to be on the long side, it's unlikely that anybody would be using anything but the latest/default version, and if they do it is possible to get it from the source/version history.
> 
> Let's clean out the old version information, leaving only the latest/default.
> 
> Testing: tier1, manually built devkits for `x86_64-linux-gnu-to-{x86_64,aarch64,ppc64le,riscv64,s390x}-linux-gnu` and then built the JDK using those devkits.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24784#pullrequestreview-2787533753

From erikj at openjdk.org  Wed Apr 23 14:26:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Apr 2025 14:26:57 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
Message-ID: <tvLHLOPHdDP5mmfigOiyH2kvyYy5dkrXNAhIscpZbZM=.0b1c095f-15fe-4951-8870-312173061680@github.com>

On Tue, 22 Apr 2025 23:05:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

Build change looks trivially good.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2824495947

From erikj at openjdk.org  Wed Apr 23 14:36:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Apr 2025 14:36:55 GMT
Subject: RFR: 8355400: Better git detection in update_copyright_year.sh
In-Reply-To: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
References: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
Message-ID: <dCaQLzo4XtWhup_ogQQvIcnwTg7UKxYib5gr8kr82TU=.04d558b6-bf0f-4bf2-a7f9-b0f386575b3d@github.com>

On Wed, 23 Apr 2025 13:19:19 GMT, Manuel H?ssig <duke at openjdk.org> wrote:

> The script `make/scripts/update_copyright.sh` relies on the path to the script for git detection, which is fragile or does not work at all or git worktrees. This PR uses git itself to detect whether the script is running in a git repository. This has the added benefit that the script can be executed from anywhere in the repository.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24828#pullrequestreview-2787576772

From lmesnik at openjdk.org  Wed Apr 23 16:15:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 23 Apr 2025 16:15:56 GMT
Subject: Integrated: 8353214: Add testing with --enable-preview
In-Reply-To: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
References: <-PL85c8ObM1KN0uVIMTglhh6apK6fWXHFO_XdbE0UWI=.589ff6c6-b65a-48c8-807a-1960d72cac09@github.com>
Message-ID: <T9zGi_nsOWhfre9491LQLlxXGXNF4SpicObz-xcPAT4=.39ffb974-7a8c-49f9-8f8c-d20054b59914@github.com>

On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Added problemlists and and requires for execution tests with --enable-preview.
> 
> The --enable-preview features might significantly change VM/JDK behavior and sometimes it is useful to run tests with preview features enabled. Eventually preview features should be made default and it is expected that all tests should still work. 
> 
> The tests that are not compatible with --enable-preview, usually because of compilation mode are marked with corresponding requires tag.

This pull request has now been integrated.

Changeset: 2ec61f0f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ec61f0f34d2fa313ae3ed5d6aa0881ec091b347
Stats:     69 lines in 4 files changed: 69 ins; 0 del; 0 mod

8353214: Add testing with --enable-preview

Reviewed-by: erikj

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

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

From liach at openjdk.org  Wed Apr 23 16:27:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Apr 2025 16:27:48 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <1PeM_xedNc1XFeq1hausCgntpYCIDrpnZ9jtLT05_rc=.265cb3d5-fa8d-4a6e-9430-1f5971c2b718@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

We don't have enough reviewer in Javadoc area; @nizarbenalla please consider reviewing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24417#issuecomment-2824856540

From nbenalla at openjdk.org  Wed Apr 23 16:33:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 23 Apr 2025 16:33:57 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <H96rOkRFU8CuMs3aXU-bDEz57u9ihuIS2RpPTN0odEU=.f6a46f9c-3fef-47a7-8d05-c97d065ab35c@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

I see that the PR requires 2 reviewers, I'll take a look tomorrow. Thanks for the ping.

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

PR Comment: https://git.openjdk.org/jdk/pull/24417#issuecomment-2824874228

From kvn at openjdk.org  Wed Apr 23 17:17:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Apr 2025 17:17:43 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <tvLHLOPHdDP5mmfigOiyH2kvyYy5dkrXNAhIscpZbZM=.0b1c095f-15fe-4951-8870-312173061680@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <tvLHLOPHdDP5mmfigOiyH2kvyYy5dkrXNAhIscpZbZM=.0b1c095f-15fe-4951-8870-312173061680@github.com>
Message-ID: <hf3Ckjyh4J3DCKz0esw3zWaOlZ8YAwYy41DUPiRBPtk=.b9a6f34f-e6c2-4aac-bdcb-ef8c951cc3d8@github.com>

On Wed, 23 Apr 2025 14:24:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> Build change looks trivially good.

Thank you, @erikj79

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2824992535

From erikj at openjdk.org  Wed Apr 23 17:17:47 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Apr 2025 17:17:47 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <ATwz9CRx9g2k8lfDjw2fiJnv9iQ3OiowpPRfQ06Q2IM=.78fee093-0e72-4c3f-a8bc-52d3a32aa02d@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

I verified that the makefile, configure and failure_handler changes are working in our internal test system. I can't review the jpackage changes.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2788157583

From vlivanov at openjdk.org  Thu Apr 24 01:56:43 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 24 Apr 2025 01:56:43 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
Message-ID: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>

On Tue, 22 Apr 2025 23:05:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

Finished the first pass over the code.


Overall, looks good. Some feedback follows.

src/hotspot/share/cds/aotCacheAccess.hpp line 38:

> 36: // AOT Cache API for AOT compiler
> 37: 
> 38: class AOTCacheAccess : AllStatic {

It looks related to `AOTCodeCache`? Maybe `AOTCodeCacheAccess` then?

src/hotspot/share/cds/aotCacheAccess.hpp line 40:

> 38: class AOTCacheAccess : AllStatic {
> 39: public:
> 40:   static void* allocate_aot_code(size_t size) NOT_CDS_RETURN_(nullptr);

"allocate_aot_code_region", "get_aot_code_region_size", and "map_aot_code_region" would be clearer.

src/hotspot/share/code/aotCodeCache.cpp line 62:

> 60: }
> 61: 
> 62: static void exit_vm_on_store_failure() {

It's a bit confusing to see `exit_vm_on_load_failure()` and `exit_vm_on_store_failure()` to silently proceed unless a flag is explicitly specified.

Moreover, how reliable `AOTAdapterCaching = false` to fail-fast and avoid repreated load/store attempts? At least, I see that `AOTCodeCache` ctor cache `AOTAdapterCaching`, so it won't see the update.

How does it affect adapter code generation during assembly phase?

src/hotspot/share/code/aotCodeCache.cpp line 645:

> 643:     return false;
> 644:   }
> 645:   log_info(aot, codecache, stubs)("Writing blob '%s' to AOT Code Cache", name);

I'd revisit logging code in AOTCodeCache and downgrade info->debug and debug->trace where appropriate. It feels too low-level most of the time.

src/hotspot/share/runtime/sharedRuntime.cpp line 2966:

> 2964:     adapter_blob = AdapterHandlerLibrary::link_aot_adapter_handler(this);
> 2965:     if (adapter_blob == nullptr) {
> 2966:       log_warning(cds)("Failed to link AdapterHandlerEntry (fp=%s) to its code in the AOT code cache", _fingerprint->as_basic_args_string());

Doesn't it add noise in the output for not yet seen adapter shapes? It's a warning.

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

PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2789025188
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057119115
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057115219
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057207417
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057187511
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057189917

From iklam at openjdk.org  Thu Apr 24 02:20:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Apr 2025 02:20:42 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
Message-ID: <0hoQ2BKezGCepBeBlxwfXUHw82Vk4Oia58NHyyD3KiM=.d6bcdd70-cc42-4dca-adff-0d881e60f979@github.com>

On Thu, 24 Apr 2025 00:51:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/cds/aotCacheAccess.hpp line 38:
> 
>> 36: // AOT Cache API for AOT compiler
>> 37: 
>> 38: class AOTCacheAccess : AllStatic {
> 
> It looks related to `AOTCodeCache`? Maybe `AOTCodeCacheAccess` then?

This file is called https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/cds/cdsAccess.hpp in the Leyden repo and provides an abstract API for accessing contents of the AOT cache. In Leyden, we have APIs for accessing cached oops:


  static int get_archived_object_permanent_index(oop obj) NOT_CDS_JAVA_HEAP_RETURN_(-1);
  static oop get_archived_object(int permanent_index) NOT_CDS_JAVA_HEAP_RETURN_(nullptr);


and various pointer operations


  static uint delta_from_shared_address_base(address addr);

  template <typename T>
  static void set_pointer(T** ptr, T* value) {
    set_pointer((address*)ptr, (address)value);
  }
  static void set_pointer(address* ptr, address value);


Let's keep the AOTCacheAccess name for now and wait until we merge this PR down to the Leyden repo. There's some overlap between AOTCacheAccess and CDSConfig. Maybe we should do a refactor/rename later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2057251128

From duke at openjdk.org  Thu Apr 24 08:34:48 2025
From: duke at openjdk.org (duke)
Date: Thu, 24 Apr 2025 08:34:48 GMT
Subject: RFR: 8355400: Better git detection in update_copyright_year.sh
In-Reply-To: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
References: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
Message-ID: <9nL1X0HmJ1z-IBqJuGey3n_ibF3OR0O9v_jaPn2o6s8=.b807c2ef-4ec9-442e-89a9-81f0758b62f7@github.com>

On Wed, 23 Apr 2025 13:19:19 GMT, Manuel H?ssig <duke at openjdk.org> wrote:

> The script `make/scripts/update_copyright.sh` relies on the path to the script for git detection, which is fragile or does not work at all or git worktrees. This PR uses git itself to detect whether the script is running in a git repository. This has the added benefit that the script can be executed from anywhere in the repository.

@mhaessig 
Your change (at version 8aee7a3be34718b3389a366fb4ddb72d6ea69612) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24828#issuecomment-2826797122

From duke at openjdk.org  Thu Apr 24 08:39:49 2025
From: duke at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 24 Apr 2025 08:39:49 GMT
Subject: Integrated: 8355400: Better git detection in update_copyright_year.sh
In-Reply-To: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
References: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
Message-ID: <c_hTXhQXDJE1_WxGA0Gu6eLA2jg5QHC3eTqoRDHP8NM=.0432d23f-de77-4716-a4e6-016237b72563@github.com>

On Wed, 23 Apr 2025 13:19:19 GMT, Manuel H?ssig <duke at openjdk.org> wrote:

> The script `make/scripts/update_copyright.sh` relies on the path to the script for git detection, which is fragile or does not work at all or git worktrees. This PR uses git itself to detect whether the script is running in a git repository. This has the added benefit that the script can be executed from anywhere in the repository.

This pull request has now been integrated.

Changeset: 290d24d1
Author:    Manuel H?ssig <manuel.hassig at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/290d24d16adcef6b9f0f5ac789b125fd7bac66a5
Stats:     13 lines in 1 file changed: 6 ins; 4 del; 3 mod

8355400: Better git detection in update_copyright_year.sh

Reviewed-by: erikj, chagedorn

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

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

From chagedorn at openjdk.org  Thu Apr 24 08:39:48 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 24 Apr 2025 08:39:48 GMT
Subject: RFR: 8355400: Better git detection in update_copyright_year.sh
In-Reply-To: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
References: <8Asbmh4W7ZmKtK1sUc0433wk1pey82oZpvoFIDBvjpg=.53f6883c-e1b8-4007-912b-11bf1b67a242@github.com>
Message-ID: <wDMjIrUjI_MggsdPq6fNdTSvBPgcHVhIh4-F0nleV6k=.302069ed-6e7e-4de7-ba0b-36b201f7cebb@github.com>

On Wed, 23 Apr 2025 13:19:19 GMT, Manuel H?ssig <duke at openjdk.org> wrote:

> The script `make/scripts/update_copyright.sh` relies on the path to the script for git detection, which is fragile or does not work at all or git worktrees. This PR uses git itself to detect whether the script is running in a git repository. This has the added benefit that the script can be executed from anywhere in the repository.

Looks good to me, too.

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24828#pullrequestreview-2790236398

From mbaesken at openjdk.org  Thu Apr 24 09:11:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Apr 2025 09:11:55 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible [v2]
In-Reply-To: <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
Message-ID: <xv5cwgjYnuu_MCcFGVQjVREHRl4p98nS7-kBb6fhLOg=.e7e39c9f-ac1d-4d83-80fd-2cb699c5f8d8@github.com>

On Thu, 17 Apr 2025 15:42:09 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
>> Unfortunately there has to be some adoptions.
>> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
>> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
>> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comments

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24667#pullrequestreview-2790355035

From jiangli at openjdk.org  Thu Apr 24 15:07:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Apr 2025 15:07:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <jyPrzI1OWFjry2KWMvIgoC89Z8jKFX8etExwzTpwZFk=.a33e3969-426d-409d-b8c1-48b093faf534@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <jyPrzI1OWFjry2KWMvIgoC89Z8jKFX8etExwzTpwZFk=.a33e3969-426d-409d-b8c1-48b093faf534@github.com>
Message-ID: <xCShwHyOQVfGaGc7Nmb7mTIAtXK8NfHSKv6bNhngy04=.4e1ee884-75bb-46eb-bfaf-39e9e445e047@github.com>

On Tue, 22 Apr 2025 21:32:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> `sysLookup` does look much cleaner compared to `jdkLibraryPath`.

@liach @slowhog Can you approve the change? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2827970628

From henryjen at openjdk.org  Thu Apr 24 15:16:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 24 Apr 2025 15:16:54 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: <QYNX3eZ11ioKOe2xDCEGclS2pqr2cowTpE6qe3B9P8Y=.acf492bb-ef98-4949-9266-4cffccf1596a@github.com>

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include <jni.h>'.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     @SuppressWarnings("restricted")
> 134:     private static SymbolLookup sysLookup() {
> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);

I would have @mcimadamore or @JornVernee look at this for the native function call permission requirements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058685087

From nbenalla at openjdk.org  Thu Apr 24 15:25:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 24 Apr 2025 15:25:51 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <zi8SacMf1zHzOX2c-PqLIm1SM_Hm_R9ERDT8WWKhjI4=.e6e913e7-93b3-4ad0-816a-25d76148d703@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

Javadoc changes look good! I also checked that the test runs fine when using `make test TEST=<path>/TestSyntaxHighlightOption.java`.

I wonder if we can push for the conversion of some  `<blockquore><pre>` to `@snippet` so that we can benefit more from this new feature. I checked some older classes and the use of `<blockquore><pre>` is still widespread.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24417#pullrequestreview-2791628352

From mikael at openjdk.org  Thu Apr 24 15:57:55 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 24 Apr 2025 15:57:55 GMT
Subject: RFR: 8355235: Clean out old versions from Tools.gmk
In-Reply-To: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
References: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
Message-ID: <jmTPUZk7iUWf-WY-cabrHIULymVHL3E0zPM26JAPSA4=.39d91323-560c-462d-9af6-aab17efa4586@github.com>

On Mon, 21 Apr 2025 22:51:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Traditionally, when upgrading the versions of the components (gcc, binutils, etc.) in Tools.gmk, the old versions/definitions have been preserved. The list is now starting to be on the long side, it's unlikely that anybody would be using anything but the latest/default version, and if they do it is possible to get it from the source/version history.
> 
> Let's clean out the old version information, leaving only the latest/default.
> 
> Testing: tier1, manually built devkits for `x86_64-linux-gnu-to-{x86_64,aarch64,ppc64le,riscv64,s390x}-linux-gnu` and then built the JDK using those devkits.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24784#issuecomment-2828122609

From mikael at openjdk.org  Thu Apr 24 15:57:56 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 24 Apr 2025 15:57:56 GMT
Subject: Integrated: 8355235: Clean out old versions from Tools.gmk
In-Reply-To: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
References: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
Message-ID: <13AB7Kr91IDOIMFBjhfX4RMBQvwLIWt-oRBPvSaIJz8=.1535c3ad-1a8f-4feb-97b6-0669d01fbfb4@github.com>

On Mon, 21 Apr 2025 22:51:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Traditionally, when upgrading the versions of the components (gcc, binutils, etc.) in Tools.gmk, the old versions/definitions have been preserved. The list is now starting to be on the long side, it's unlikely that anybody would be using anything but the latest/default version, and if they do it is possible to get it from the source/version history.
> 
> Let's clean out the old version information, leaving only the latest/default.
> 
> Testing: tier1, manually built devkits for `x86_64-linux-gnu-to-{x86_64,aarch64,ppc64le,riscv64,s390x}-linux-gnu` and then built the JDK using those devkits.

This pull request has now been integrated.

Changeset: 751e0392
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/751e0392bcad0e608a7a041b658c1d263383f15a
Stats:     120 lines in 1 file changed: 13 ins; 93 del; 14 mod

8355235: Clean out old versions from Tools.gmk

Reviewed-by: erikj

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

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

From kvn at openjdk.org  Thu Apr 24 17:05:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Apr 2025 17:05:43 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <0hoQ2BKezGCepBeBlxwfXUHw82Vk4Oia58NHyyD3KiM=.d6bcdd70-cc42-4dca-adff-0d881e60f979@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
 <0hoQ2BKezGCepBeBlxwfXUHw82Vk4Oia58NHyyD3KiM=.d6bcdd70-cc42-4dca-adff-0d881e60f979@github.com>
Message-ID: <UMYZRMQ3RW_eKtsxml8IXgjRhMLp49_pTSXjbwPqMIM=.610f873c-a3b9-4e53-8909-976adc74baa3@github.com>

On Thu, 24 Apr 2025 02:18:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotCacheAccess.hpp line 38:
>> 
>>> 36: // AOT Cache API for AOT compiler
>>> 37: 
>>> 38: class AOTCacheAccess : AllStatic {
>> 
>> It looks related to `AOTCodeCache`? Maybe `AOTCodeCacheAccess` then?
>
> This file is called https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/cds/cdsAccess.hpp in the Leyden repo and provides an abstract API for accessing contents of the AOT cache. In Leyden, we have APIs for accessing cached oops:
> 
> 
>   static int get_archived_object_permanent_index(oop obj) NOT_CDS_JAVA_HEAP_RETURN_(-1);
>   static oop get_archived_object(int permanent_index) NOT_CDS_JAVA_HEAP_RETURN_(nullptr);
> 
> 
> and various pointer operations
> 
> 
>   static uint delta_from_shared_address_base(address addr);
> 
>   template <typename T>
>   static void set_pointer(T** ptr, T* value) {
>     set_pointer((address*)ptr, (address)value);
>   }
>   static void set_pointer(address* ptr, address value);
> 
> 
> Let's keep the AOTCacheAccess name for now and wait until we merge this PR down to the Leyden repo. There's some overlap between AOTCacheAccess and CDSConfig. Maybe we should do a refactor/rename later.

Okay, I will keep the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2058883661

From liach at openjdk.org  Thu Apr 24 17:38:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Apr 2025 17:38:58 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <QYNX3eZ11ioKOe2xDCEGclS2pqr2cowTpE6qe3B9P8Y=.acf492bb-ef98-4949-9266-4cffccf1596a@github.com>
 <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>
Message-ID: <kd7PxlN5YCxb1U9grGG09WYhQij6O98r3v2Ri2amV3Y=.3d5be32b-6458-4d76-b524-89ccd7431d8b@github.com>

On Thu, 24 Apr 2025 17:33:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:
>> 
>>> 133:     @SuppressWarnings("restricted")
>>> 134:     private static SymbolLookup sysLookup() {
>>> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);
>> 
>> I would consult @mcimadamore or @JornVernee look at this for the native function call permission requirements.
>
> @mcimadamore or @JornVernee Can you help take a look of this? Thanks!

Unfortunately, I believe both of them are on vacation, yet they have the required expertise to review this PR. You might need to wait a bit, sorry!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058934598

From jiangli at openjdk.org  Thu Apr 24 17:38:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Apr 2025 17:38:57 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <QYNX3eZ11ioKOe2xDCEGclS2pqr2cowTpE6qe3B9P8Y=.acf492bb-ef98-4949-9266-4cffccf1596a@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <QYNX3eZ11ioKOe2xDCEGclS2pqr2cowTpE6qe3B9P8Y=.acf492bb-ef98-4949-9266-4cffccf1596a@github.com>
Message-ID: <25tnSBnETNb-3aQ_iMam3rpQhBIE08B3042wfpNlAWo=.14fa57d1-e03b-46e5-80a5-c8b747db1826@github.com>

On Thu, 24 Apr 2025 15:14:27 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:
> 
>> 133:     @SuppressWarnings("restricted")
>> 134:     private static SymbolLookup sysLookup() {
>> 135:         NativeLibraries libs = NativeLibraries.newInstance(null);
> 
> I would consult @mcimadamore or @JornVernee look at this for the native function call permission requirements.

@mcimadamore or @JornVernee Can you help take a look of this? Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24801#discussion_r2058930806

From asmehra at openjdk.org  Thu Apr 24 20:46:51 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 24 Apr 2025 20:46:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
Message-ID: <906foFPYK2MMXfRZN4BbdV6cgV7LwG26qTsp0_IASzw=.29a21e39-fde8-41fb-8322-30b154800261@github.com>

On Thu, 24 Apr 2025 01:39:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2966:
> 
>> 2964:     adapter_blob = AdapterHandlerLibrary::link_aot_adapter_handler(this);
>> 2965:     if (adapter_blob == nullptr) {
>> 2966:       log_warning(cds)("Failed to link AdapterHandlerEntry (fp=%s) to its code in the AOT code cache", _fingerprint->as_basic_args_string());
> 
> Doesn't it add noise in the output for not yet seen adapter shapes? It's a warning.

`AdapterHandlerEntry::link` method gets called only for the archived adapters. Not yet seen adapters do not come across this code path. Reason for making it a warning is the assumption that, if the AOT Code Cache is usable, then we should always be able to link the `AdapterHandlerEntry` to its code in the AOT code cache. If we fail to do so, then something is not right in this machinery and likely pointing to a bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059204247

From mikael at openjdk.org  Thu Apr 24 21:29:41 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 24 Apr 2025 21:29:41 GMT
Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle
Message-ID: <thFDDcVLix_-gk7TLl464NFx_Ajes-oC4YONSwsgp-0=.66d42c84-e94b-4810-b508-5e86a840a1d3@github.com>

Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4.

Testing: tier1-5

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

Commit messages:
 - Update doc/building.md to reflect updated macOS/Xcode versions
 - 8355446: Change to Xcode 15.4 for building on macOS at Oracle

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

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

From kvn at openjdk.org  Thu Apr 24 23:52:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Apr 2025 23:52:59 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
Message-ID: <MHy19nfEQ5ImZFHfhHAuBxl93cJHLYZI5ui1shI07T4=.3dbf195e-4216-480c-bb38-bd1635cb7afb@github.com>

On Thu, 24 Apr 2025 00:49:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/cds/aotCacheAccess.hpp line 40:
> 
>> 38: class AOTCacheAccess : AllStatic {
>> 39: public:
>> 40:   static void* allocate_aot_code(size_t size) NOT_CDS_RETURN_(nullptr);
> 
> "allocate_aot_code_region", "get_aot_code_region_size", and "map_aot_code_region" would be clearer.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059381865

From kvn at openjdk.org  Fri Apr 25 00:36:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Apr 2025 00:36:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
Message-ID: <qSkRnTWNpWPt5Op3DBBh8TiJdsfqx5KsJPMjARa2YcA=.aeea8ec6-3267-4897-b43a-343c707ab9bd@github.com>

On Thu, 24 Apr 2025 01:37:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/code/aotCodeCache.cpp line 645:
> 
>> 643:     return false;
>> 644:   }
>> 645:   log_info(aot, codecache, stubs)("Writing blob '%s' to AOT Code Cache", name);
> 
> I'd revisit logging code in AOTCodeCache and downgrade info->debug and debug->trace where appropriate. It feels too low-level most of the time.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059406950

From kvn at openjdk.org  Fri Apr 25 00:47:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Apr 2025 00:47:52 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
Message-ID: <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>

On Thu, 24 Apr 2025 01:51:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix message
>
> src/hotspot/share/code/aotCodeCache.cpp line 62:
> 
>> 60: }
>> 61: 
>> 62: static void exit_vm_on_store_failure() {
> 
> It's a bit confusing to see `exit_vm_on_load_failure()` and `exit_vm_on_store_failure()` to silently proceed unless a flag is explicitly specified.
> 
> Moreover, how reliable `AOTAdapterCaching = false` to fail-fast and avoid repreated load/store attempts? At least, I see that `AOTCodeCache` ctor cache `AOTAdapterCaching`, so it won't see the update.
> 
> How does it affect adapter code generation during assembly phase?

We check failure state of AOT code cache when query about using adapters caching:

  bool for_use()  const { return _for_use  && !_failed; }
  bool for_dump() const { return _for_dump && !_failed; }
  static bool is_on() CDS_ONLY({ return _cache != nullptr && !_cache->closing(); }) NOT_CDS_RETURN_(false);
  static bool is_on_for_use()  { return is_on() && _cache->for_use(); }
  static bool is_on_for_dump() { return is_on() && _cache->for_dump(); }



  static bool is_dumping_adapters() { return is_on_for_dump() && _cache->adapter_caching(); }
  static bool is_using_adapters()   { return is_on_for_use() && _cache->adapter_caching(); }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059412190

From kvn at openjdk.org  Fri Apr 25 00:51:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Apr 2025 00:51:53 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
 <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>
Message-ID: <sAj_5Nc4IQF_zqXtKB38KvFGQmeKtrlwpb9Ag7TdpuE=.596532a6-cd43-472c-a094-77cdabbf0ae6@github.com>

On Fri, 25 Apr 2025 00:44:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/aotCodeCache.cpp line 62:
>> 
>>> 60: }
>>> 61: 
>>> 62: static void exit_vm_on_store_failure() {
>> 
>> It's a bit confusing to see `exit_vm_on_load_failure()` and `exit_vm_on_store_failure()` to silently proceed unless a flag is explicitly specified.
>> 
>> Moreover, how reliable `AOTAdapterCaching = false` to fail-fast and avoid repreated load/store attempts? At least, I see that `AOTCodeCache` ctor cache `AOTAdapterCaching`, so it won't see the update.
>> 
>> How does it affect adapter code generation during assembly phase?
>
> We check failure state of AOT code cache when query about using adapters caching:
> 
>   bool for_use()  const { return _for_use  && !_failed; }
>   bool for_dump() const { return _for_dump && !_failed; }
>   static bool is_on() CDS_ONLY({ return _cache != nullptr && !_cache->closing(); }) NOT_CDS_RETURN_(false);
>   static bool is_on_for_use()  { return is_on() && _cache->for_use(); }
>   static bool is_on_for_dump() { return is_on() && _cache->for_dump(); }
> 
> 
> 
>   static bool is_dumping_adapters() { return is_on_for_dump() && _cache->adapter_caching(); }
>   static bool is_using_adapters()   { return is_on_for_use() && _cache->adapter_caching(); }

AOT adapters code caching and loading is guarded by these methods not by flag.

Setting AOTAdapterCaching to false on failure is simple indication that adapter caching is switched off for someone who will look on final state of flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059413988

From kvn at openjdk.org  Fri Apr 25 00:54:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Apr 2025 00:54:48 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <sAj_5Nc4IQF_zqXtKB38KvFGQmeKtrlwpb9Ag7TdpuE=.596532a6-cd43-472c-a094-77cdabbf0ae6@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
 <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>
 <sAj_5Nc4IQF_zqXtKB38KvFGQmeKtrlwpb9Ag7TdpuE=.596532a6-cd43-472c-a094-77cdabbf0ae6@github.com>
Message-ID: <2q_jgLrJim5ntOfr3awHdl1HTgrWtcTdcHWsO_CfnHU=.7958f1ef-9792-416a-9474-33f776e01fb5@github.com>

On Fri, 25 Apr 2025 00:48:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We check failure state of AOT code cache when query about using adapters caching:
>> 
>>   bool for_use()  const { return _for_use  && !_failed; }
>>   bool for_dump() const { return _for_dump && !_failed; }
>>   static bool is_on() CDS_ONLY({ return _cache != nullptr && !_cache->closing(); }) NOT_CDS_RETURN_(false);
>>   static bool is_on_for_use()  { return is_on() && _cache->for_use(); }
>>   static bool is_on_for_dump() { return is_on() && _cache->for_dump(); }
>> 
>> 
>> 
>>   static bool is_dumping_adapters() { return is_on_for_dump() && _cache->adapter_caching(); }
>>   static bool is_using_adapters()   { return is_on_for_use() && _cache->adapter_caching(); }
>
> AOT adapters code caching and loading is guarded by these methods not by flag.
> 
> Setting AOTAdapterCaching to false on failure is simple indication that adapter caching is switched off for someone who will look on final state of flag.

I added `log_info()` to `exit_vm_on_*_failure()` methods to produce notification when AbortVMOnAOTCodeFailure flag is off (default value).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2059415739

From amitkumar at openjdk.org  Fri Apr 25 06:30:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 25 Apr 2025 06:30:41 GMT
Subject: RFR: 8355570: [s390x] Update -march to z13 generation
Message-ID: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>

updated march level from z10 to z13.

Testing: tier1 (fastdebug-vm)

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

Commit messages:
 - z10 -> z15

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

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

From serb at openjdk.org  Fri Apr 25 07:29:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 25 Apr 2025 07:29:50 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <o1f3SIzBzkjqxKoG76sTKDEjJBnTVWuYNkKEtSCUwPQ=.cb3dd755-cc12-42ab-9772-eba15625ebf5@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

.editorconfig line 10:

> 8: 
> 9: [src/hotspot/**.{cpp,hpp,h}]
> 10: indent_style = space

Just wondering - will the new src/hotspot block inherit the trim_trailing_whitespace setting from the top-level [*] block?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24714#discussion_r2059707340

From mbaesken at openjdk.org  Fri Apr 25 08:18:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Apr 2025 08:18:01 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible [v2]
In-Reply-To: <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
Message-ID: <XFySTIirBpIsAmXPkR1oWl4f1XUmRUEsBhYme1N6liw=.983acd86-f87e-4a72-93d8-c11402e8e0f1@github.com>

On Thu, 17 Apr 2025 15:42:09 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
>> Unfortunately there has to be some adoptions.
>> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
>> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
>> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comments

When doing a ubsan enabled build on AIX I also noticed the following


warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
3 warnings generated.
warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
3 warnings generated.



Seems a couple of warning related flags that are set when running an ubsan enabled build do not exist on AIX (or generally with clang ?).
Maybe we should address/adjust this too. See line 523 in jdk-options.m4 just above your patch; 
probably those options came from gcc ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24667#issuecomment-2829697197

From jpai at openjdk.org  Fri Apr 25 11:34:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 11:34:57 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: <WZllr04PKhC-grLdp_uaolZfRJwyrphG4dkciEECc6w=.ce4f45e6-f28b-4f10-ac71-7fb0b300ed63@github.com>

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include <jni.h>'.

Hello Jiangli, if I understand this change correctly, then this is forcing a non-JNI library to be a JNI library for it to work on static JDK. Is that a requirement for static JDK builds? Or is it just a convenient way to use existing library loading mechanism in the `jdk.internal.loader.NativeLibraries`?

Are there other similar libraries shipped in JAVA_HOME/lib that would require a similar change/treatment?

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

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2830165959

From hannesw at openjdk.org  Fri Apr 25 12:08:56 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Apr 2025 12:08:56 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <zi8SacMf1zHzOX2c-PqLIm1SM_Hm_R9ERDT8WWKhjI4=.e6e913e7-93b3-4ad0-816a-25d76148d703@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
 <zi8SacMf1zHzOX2c-PqLIm1SM_Hm_R9ERDT8WWKhjI4=.e6e913e7-93b3-4ad0-816a-25d76148d703@github.com>
Message-ID: <cbJO2ChyJj_obGaUOyvlIdTVfzLFvzHqAd2s7-EKnTE=.6fac7bd8-a133-4f4f-9f46-425ad350b232@github.com>

On Thu, 24 Apr 2025 15:22:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I wonder if we can push for the conversion of some `<blockquore><pre>` to `@snippet` so that we can benefit more from this new feature. I checked some older classes and the use of `<blockquore><pre>` is still widespread.

`<pre><code>` is supported by syntax highlighting, so the simplest way to fix `<blockquote><pre>` would be to add a `<code>` element or `{@code}` tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/24417#issuecomment-2830241236

From erikj at openjdk.org  Fri Apr 25 12:46:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Apr 2025 12:46:53 GMT
Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle
In-Reply-To: <thFDDcVLix_-gk7TLl464NFx_Ajes-oC4YONSwsgp-0=.66d42c84-e94b-4810-b508-5e86a840a1d3@github.com>
References: <thFDDcVLix_-gk7TLl464NFx_Ajes-oC4YONSwsgp-0=.66d42c84-e94b-4810-b508-5e86a840a1d3@github.com>
Message-ID: <PudTukam_Ab8OZnXNj7rNCWjb7dM1KccD0-VpOCfwIk=.e478c5d1-135a-46c3-b5d9-7448dcabcae7@github.com>

On Thu, 24 Apr 2025 20:55:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4.
> 
> Testing: tier1-5

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24862#pullrequestreview-2794004772

From erikj at openjdk.org  Fri Apr 25 12:48:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Apr 2025 12:48:54 GMT
Subject: RFR: 8355570: [s390x] Update -march to z13 generation
In-Reply-To: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
References: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
Message-ID: <bOmqXjHf4lWJNqlaBfxbcITkdoNzHijVKB_ByvBClZY=.cbea1e41-8c5a-403b-8600-381a5039e5f5@github.com>

On Fri, 25 Apr 2025 06:24:31 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> updated march level from z10 to z13.
> 
> Testing: tier1 (fastdebug-vm)

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24869#pullrequestreview-2794009150

From matthias.baesken at sap.com  Fri Apr 25 14:28:19 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 25 Apr 2025 14:28:19 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
Message-ID: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi,  Memory sanitizer
https://clang.llvm.org/docs/MemorySanitizer.html

is supported with the clang toolchain  (e.g. on Linux) ;  ?MemorySanitizer is a detector of uninitialized memory use?  .

For small examples it is rather easy to use,   you just compile and link   with   -fsanitize=memory      (and for better results maybe additionally  -fno-omit-frame-pointer )   .

So I gave it a try with OpenJDK too and added   -fsanitize=memory      to the  C/CXX and LD flags  (--with-extra-cflags=-fsanitize=memory --with-extra-cxxflags=-fsanitize=memory --with-extra-ldflags=-fsanitize=memory ).
As far as compiling single  compilation units this seems to be okay .
But when it comes to executing the new generated binaries in the build process  we unfortunately  get  lookup errors / undefined symbols   :

/builddir/jdk/bin/javac: symbol lookup error:  /builddir/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls


Is there something special in our OpenJDK  build that causes trouble here ?


Here I found an somewhat similar looking issue :
https://groups.google.com/g/memory-sanitizer/c/xV3OZZCiL9A

where re-exporting symbols is mentioned -  is this maybe something that hits us in OpenJDK too ?


For address sanitizer, we set  -shared-libasan in the OpenJDK :

https://github.com/openjdk/jdk/blob/5c067232bf21aaca2b7addd2a862e15a8696ffb8/make/autoconf/jdk-options.m4#L449
ASAN_LDFLAGS="$ASAN_LDFLAGS -shared-libasan"

But I could not find something similar for msan .


(btw. I use clang 15.0.7 on SUSE Linux x86_64 in case this matters)


Best regards, Matthias







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250425/b5df8d04/attachment-0001.htm>

From nbenalla at openjdk.org  Fri Apr 25 16:50:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 25 Apr 2025 16:50:48 GMT
Subject: RFR: 8348282: Add option for syntax highlighting in javadoc
 snippets [v4]
In-Reply-To: <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
 <ThoL5cmF6HrddzN4k0Gav0eTopSMI2oh659K2RQlwY0=.b3912fd8-2df7-4907-885f-ca7bba247ef1@github.com>
Message-ID: <owSJQ1olb0qgFkzrPHbd7o9BISG9IEt1a-_SxbU5HRA=.b5839916-9952-450d-8458-1a61b1a273d9@github.com>

On Wed, 9 Apr 2025 04:15:20 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust color palette

Thanks for clearing this up, I was looking at the class description of `String.java` where the javadoc is missing `<code>`/`{@code}`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24417#issuecomment-2830914866

From jiangli at openjdk.org  Fri Apr 25 19:19:46 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 25 Apr 2025 19:19:46 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <WZllr04PKhC-grLdp_uaolZfRJwyrphG4dkciEECc6w=.ce4f45e6-f28b-4f10-ac71-7fb0b300ed63@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <WZllr04PKhC-grLdp_uaolZfRJwyrphG4dkciEECc6w=.ce4f45e6-f28b-4f10-ac71-7fb0b300ed63@github.com>
Message-ID: <qHOonqvuzZNmGbdfgtR_Z623D8xY42W_hnURWwLZ_xc=.7a26abe6-361a-4e6c-b8e5-3256493c80eb@github.com>

On Fri, 25 Apr 2025 11:31:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Jiangli, if I understand this change correctly, then this is forcing a non-JNI library to be a JNI library for it to work on static JDK. Is that a requirement for static JDK builds? Or is it just a convenient way to use existing library loading mechanism in the `jdk.internal.loader.NativeLibraries`?
> 

Hi @jaikiran Good questions. I kind of expected questions like those might be raised with the addition of `DEF_STATIC_JNI_OnLoad` to `libsyslookup`, when I made the change.

The original static built-in JNI library support in JDK was added by JEP 178 (https://openjdk.org/jeps/178) "Statically-Linked JNI Libraries" work. It's on top of the JNI library support. Both spec & implementation expected `JNI_OnLoad_L` (L as the library name) in a statically linked JNI library. From JNI spec (https://docs.oracle.com/en/java/javase/24/docs/specs/jni/invocation.html#jni_onload_l):


JNI_OnLoad_L
jint JNI_Onload_<L>(JavaVM *vm, void *reserved);

Mandatory function that must be defined by statically linked libraries .

If a library, named 'L', is statically linked, then upon the first invocation of System.loadLibrary("L") or equivalent API, a JNI_OnLoad_L function will be invoked with the same arguments and expected return value as specified for the JNI_OnLoad function. JNI_OnLoad_L must return the JNI version needed by the native library. This version must be JNI_VERSION_1_8 or later. If the VM does not recognize the version number returned by JNI_OnLoad_L, the VM will act as if the library was never loaded.

LINKAGE:
Exported from statically linked native libraries that contain native method implementations.

PARAMETERS:
vm: a pointer to the current VM structure.

reserved: unused pointer.

RETURNS:
Return the required JNI_VERSION constant (see also GetVersion). The minimum version returned being at least JNI_VERSION_1_8.

SINCE:
JDK/JRE 1.8

JNI_OnUnload_L
void JNI_OnUnload_<L>(JavaVM *vm, void *reserved);

Optional function defined by statically linked libraries. When the class loader containing a statically linked native library 'L' is garbage collected, the VM will invoke the JNI_OnUnload_L function of the library if such a function is exported.

This function can be used to perform cleanup operations. Because this function is called in an unknown context (such as from a finalizer), the programmer should be conservative on using Java VM services, and refrain from arbitrary Java call-backs.

LINKAGE:
Exported from statically linked native libraries that contain native method implementations.

PARAMETERS:
vm: a pointer to the current VM structure.

reserved: unused pointer.

SINCE:
JDK/JRE 1.8

Informational Note:
The act of loading a native library is the complete process of making the library and its native entry points known and registered to the Java VM and runtime. Note that simply performing operating system level operations to load a native library, such as dlopen on a UNIX(R) system, does not fully accomplish this goal. A native function is normally called from the Java class loader to perform a call to the host operating system that will load the library into memory and return a handle to the native library. This handle will be stored and used in subsequent searches for native library entry points. The Java native class loader will complete the load process once the handle is successfully returned to register the library.


You are right that this PR change turns the `libsyslookup` from a "non-JNI" native library to JNI native library. The `DEF_STATIC_JNI_OnLoad` macro adds `JNI_OnLoad_syslookup` in libsyslookup. The `JNI_OnLoad_syslookup` symbol can be used by `Java_jdk_internal_loader_NativeLibraries_findBuiltinLib` (https://github.com/openjdk/jdk/blob/4b880299881c9413038d647123e3b658999c6f8f/src/java.base/share/native/libjava/NativeLibraries.c#L235) to find the statically linked library.

> Are there other similar libraries shipped in JAVA_HOME/lib that would require a similar change/treatment?

Yes. Our current static/hermetic work has found any missing `DEF_STATIC_JNI_OnLoad` in the JDK JNI libraries and added them.

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

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2831236496

From iveresov at openjdk.org  Fri Apr 25 20:32:28 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 25 Apr 2025 20:32:28 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
Message-ID: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>

Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.

More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

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

Commit messages:
 - Merge branch 'master' into pp
 - Add AOTCompileEagerly flag to control compilation after clinit
 - Port 8355334: [leyden] Missing type profile info in archived training data
 - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
 - Use ENABLE_IF macro
 - Missing part of the last commit
 - Fix value of CompLevel_count
 - Add test
 - Don't compile trainingData.cpp without CDS (part 2)
 - Don't compile trainingData.cpp without CDS (part 1)
 - ... and 18 more: https://git.openjdk.org/jdk/compare/5c067232...3ec132e7

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355003
  Stats: 3202 lines in 57 files changed: 2976 ins; 103 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

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

From kvn at openjdk.org  Sat Apr 26 01:30:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 26 Apr 2025 01:30:01 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
Message-ID: <OIfwWmX4LaqIxZx653q7KPM2Y3Yxit424Pq-h6Mdva0=.e94d12ed-ddaf-4ba1-8580-0813a36d0396@github.com>

On Tue, 22 Apr 2025 23:05:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

I found that C strings caching has issue - it is concurrent and needs synchronization.
Also I see a lot more strings after recent changes in mainline. After investigation I filed separate RFE for mainline and I am working on it: [JDK-8355635: Do not collect C strings in C2 scratch buffer](https://bugs.openjdk.org/browse/JDK-8355635)

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2831713648

From kvn at openjdk.org  Sat Apr 26 22:49:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 26 Apr 2025 22:49:52 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>

On Fri, 25 Apr 2025 20:18:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

In general it is okay.

Please, use UL with `(aot, training)` tags for your code.

I noticed (and added comment) that you use `guarantee()` which crashes VM when you call new `verify` methods. Can you disable TD instead and continue execution?

src/hotspot/share/cds/archiveBuilder.cpp line 770:

> 768:   relocate_embedded_pointers(&_rw_src_objs);
> 769:   relocate_embedded_pointers(&_ro_src_objs);
> 770:   log_info(cds)("Relocating %zu pointers, %zu tagged, %zu nulled",

`log_info(aot)` if it is Leyden related.

src/hotspot/share/cds/dumpAllocStats.hpp line 151:

> 149:   }
> 150: 
> 151:   void record_dynamic_proxy_class() {

This is not called. This code seems not related.

src/hotspot/share/ci/ciInstanceKlass.hpp line 47:

> 45:   friend class ciField;
> 46:   friend class ciReplay;
> 47:   friend class CompileTrainingData;

Not referenced here

src/hotspot/share/ci/ciMethod.cpp line 1147:

> 1145: // heuristic (e.g. post call nop instructions; see InlineSkippedInstructionsCounter)
> 1146: int ciMethod::inline_instructions_size() {
> 1147:   if (_inline_instructions_size == -1) {

Why repeat this condition and not put new code under existing one?

src/hotspot/share/ci/ciMethodData.cpp line 71:

> 69: 
> 70:   bool is_live(Method* m) {
> 71:     Klass* holder = m->method_holder();

Changes in this file seems not related and can be pushed/tested separately. If they are related - there should be condition for additional checks.

src/hotspot/share/ci/ciObjectFactory.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.

Wrong year

src/hotspot/share/compiler/compileBroker.hpp line 456:

> 454: };
> 455: 
> 456: class TrainingReplayThread : public JavaThread {

Add comment explaining what this thread do exactly.

src/hotspot/share/memory/allocation.cpp line 89:

> 87: }
> 88: 
> 89: // Work-around -- see JDK-8331086

We should not use bug ID in comment (here and in .hpp file). Please, explain in the comment why you do that.

src/hotspot/share/oops/methodCounters.cpp line 57:

> 55: 
> 56: MethodCounters::MethodCounters() {
> 57:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");

The same comment as for `MathodData()`.

src/hotspot/share/oops/methodCounters.cpp line 82:

> 80: 
> 81: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {
> 82:   log_trace(cds)("Iter(MethodCounters): %p", this);

Use `log_trace(aot, training)`

src/hotspot/share/oops/methodCounters.hpp line 129:

> 127:   void set_highest_osr_comp_level(int level)     { _highest_osr_comp_level = (u1)level; }
> 128: 
> 129: 

Extra empty line

src/hotspot/share/oops/methodData.cpp line 1296:

> 1294: 
> 1295: MethodData::MethodData() {
> 1296:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");

1. Should its code be guarded by `#if INCLUDE_CDS`?
2. Comment where/how it is used.
3. Is it used in all phases or only during TRAINING and ASSEMBLY?
4. Can you add query methods into `CDSConfig` which you can call here and in other places?:

 is_dumping_training_data()
 is_using_training_data()

src/hotspot/share/oops/methodData.cpp line 1434:

> 1432: 
> 1433: bool MethodData::is_mature() const {
> 1434:   return CompilationPolicy::is_mature((MethodData*)this);

Why you need the cast?

src/hotspot/share/oops/methodData.cpp line 1796:

> 1794: 
> 1795: void MethodData::metaspace_pointers_do(MetaspaceClosure* it) {
> 1796:   log_trace(cds)("Iter(MethodData): %p for %p %s", this, _method, _method->name_and_sig_as_C_string());

We discussed yesterday and we need to use `aot` instead `cds` for Leyden. `aot` tag is already in mainline. 
I suggest to use new tag `(aot, training)` to separate your output from general CDS/AOT output.

src/hotspot/share/oops/trainingData.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

Use one year

src/hotspot/share/oops/trainingData.cpp line 54:

> 52: 
> 53: MethodTrainingData::MethodTrainingData() {
> 54:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");

Consider adding and using `CDSConfig::is_dumping_training_data() ` or something.

src/hotspot/share/oops/trainingData.cpp line 76:

> 74: 
> 75: static void verify_archived_entry(TrainingData* td, const TrainingData::Key* k) {
> 76:   guarantee(TrainingData::Key::can_compute_cds_hash(k), "");

Should we gracefully disable using TD instead of crashing VM?

src/hotspot/share/oops/trainingData.cpp line 545:

> 543:     if (is_excluded) {
> 544:       ResourceMark rm;
> 545:       log_debug(cds)("Cleanup KTD %s", name()->as_klass_external_name());

`log_debug(aot, training)`

src/hotspot/share/oops/trainingData.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

This is debatable but suggestion to use only one year (2025) for new files.

src/hotspot/share/oops/trainingData.hpp line 756:

> 754:   int highest_level()         const { return highest_level(_level_mask); }
> 755:   int highest_top_level()     const { return _highest_top_level; }
> 756:   MethodData* final_profile() const { return _final_profile; }

`never_inlined()`, `highest_level()` are not used.

src/hotspot/share/runtime/init.cpp line 189:

> 187: #endif
> 188: 
> 189:   if (TrainingData::have_data() || TrainingData::need_data()) {

Why 2 checks? Comment please.

test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 30:

> 28:  * @requires vm.cds
> 29:  * @comment work around JDK-8345635
> 30:  * @requires !vm.jvmci.enabled

Consider adding:

 * @requires vm.cds.supports.aot.class.linking
 * @requires vm.flagless

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

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2796434540
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061680543
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061639984
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061668601
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061637565
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061635488
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061668094
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061631348
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061629193
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061626756
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061626460
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061626301
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061626021
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061625757
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061625222
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061687468
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061690598
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061694717
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061697540
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061627798
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061664186
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061612509
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061611330

From iveresov at openjdk.org  Sat Apr 26 23:38:46 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 26 Apr 2025 23:38:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <__a0S14OZpuwaQX6jFAlJhZJy2fZ9flb_1LW9gUD_sI=.b2b7851a-0aed-421b-9755-89fc63e404da@github.com>

On Sat, 26 Apr 2025 21:07:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/runtime/init.cpp line 189:
> 
>> 187: #endif
>> 188: 
>> 189:   if (TrainingData::have_data() || TrainingData::need_data()) {
> 
> Why 2 checks? Comment please.

Because it's only needed if we're recording or replaying. I'll add a comment.

> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 30:
> 
>> 28:  * @requires vm.cds
>> 29:  * @comment work around JDK-8345635
>> 30:  * @requires !vm.jvmci.enabled
> 
> Consider adding:
> 
>  * @requires vm.cds.supports.aot.class.linking
>  * @requires vm.flagless

Could you please explain why? @iklam, what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061836271
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061832468

From iveresov at openjdk.org  Sat Apr 26 23:46:47 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 26 Apr 2025 23:46:47 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <Kta441yaAe1GUwNnYL395t3uvnwjwUhUJ-hzM5tW3MY=.10edbe91-ae1e-42d7-ab60-3d12dce5a13b@github.com>

On Sat, 26 Apr 2025 21:28:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/oops/methodData.cpp line 1434:
> 
>> 1432: 
>> 1433: bool MethodData::is_mature() const {
>> 1434:   return CompilationPolicy::is_mature((MethodData*)this);
> 
> Why you need the cast?

To remove constness. I'll make it a const_cast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061843635

From iveresov at openjdk.org  Sat Apr 26 23:55:49 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 26 Apr 2025 23:55:49 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <PPpTstJuDUfqJQJ7c94sk-jf051i1xdAxdfRgr9M7RY=.1b74b609-261a-4788-aa97-604913bc385c@github.com>

On Sat, 26 Apr 2025 22:09:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/ci/ciMethodData.cpp line 71:
> 
>> 69: 
>> 70:   bool is_live(Method* m) {
>> 71:     Klass* holder = m->method_holder();
> 
> Changes in this file seems not related and can be pushed/tested separately. If they are related - there should be condition for additional checks.

You mean you want these checks to be done only if `TrainingData::have_data() == true` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061846315

From iveresov at openjdk.org  Sun Apr 27 00:00:56 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 00:00:56 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <cj3ZqriTDE0d_q7KaYaIdyWJe2kVAulA_uUR2NBE3Xw=.9819452b-44d3-47b1-b9ea-71e26c45dc52@github.com>

On Sat, 26 Apr 2025 22:42:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/oops/trainingData.cpp line 76:
> 
>> 74: 
>> 75: static void verify_archived_entry(TrainingData* td, const TrainingData::Key* k) {
>> 76:   guarantee(TrainingData::Key::can_compute_cds_hash(k), "");
> 
> Should we gracefully disable using TD instead of crashing VM?

But this is a verification code. That seems to be the usual strategy, is it not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061847152

From iveresov at openjdk.org  Sun Apr 27 00:05:46 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 00:05:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <bp9qLzafolLsziyaNhCq_icOAkUvttHMBfLJ-oAQJqc=.19b39f9f-9547-43e7-9c39-18d25f4fb06a@github.com>

On Sat, 26 Apr 2025 22:15:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/cds/dumpAllocStats.hpp line 151:
> 
>> 149:   }
>> 150: 
>> 151:   void record_dynamic_proxy_class() {
> 
> This is not called. This code seems not related.

True. @iklam, this came with a change you wanted me to take. Ok to cut this out?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061851887

From iveresov at openjdk.org  Sun Apr 27 00:23:45 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 00:23:45 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <pTHHmRfXblnuFwWbGxjCbTGlN10CqbJhlbyZAAKKJwo=.b598cb5d-ee90-48b9-899c-d9d9c5455770@github.com>

On Sat, 26 Apr 2025 21:30:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/oops/methodData.cpp line 1296:
> 
>> 1294: 
>> 1295: MethodData::MethodData() {
>> 1296:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");
> 
> 1. Should its code be guarded by `#if INCLUDE_CDS`?
> 2. Comment where/how it is used.
> 3. Is it used in all phases or only during TRAINING and ASSEMBLY?
> 4. Can you add query methods into `CDSConfig` which you can call here and in other places?:
> 
>  is_dumping_training_data()
>  is_using_training_data()

I think those are used for CDS serialization/deserialization, right, @iklam?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061856884

From iveresov at openjdk.org  Sun Apr 27 00:26:45 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 00:26:45 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <OoJZKZbihUQBUDK85cTK16sQQUtcAbdY-R5sntQ8zaQ=.9f20e0b4-c2ed-440a-858e-4486e4c0acc2@github.com>

On Sat, 26 Apr 2025 22:32:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/ci/ciInstanceKlass.hpp line 47:
> 
>> 45:   friend class ciField;
>> 46:   friend class ciReplay;
>> 47:   friend class CompileTrainingData;
> 
> Not referenced here

It allows `CompileTrainingData` to peek into the `ciInstanceKlass` internals. We need the klass ptr specially.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061864230

From iveresov at openjdk.org  Sun Apr 27 00:34:45 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 00:34:45 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <Kxv1lV6KehQ2LRU-uazpl5K9RsR4-AstwK3jtV3R-Ns=.b011c53d-28b0-4caa-96f6-8d309594e745@github.com>

On Sat, 26 Apr 2025 22:11:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/ci/ciMethod.cpp line 1147:
> 
>> 1145: // heuristic (e.g. post call nop instructions; see InlineSkippedInstructionsCounter)
>> 1146: int ciMethod::inline_instructions_size() {
>> 1147:   if (_inline_instructions_size == -1) {
> 
> Why repeat this condition and not put new code under existing one?

The caching logic sets the `_inline_instructions_size` if the value is found in the archive. The normal logic doesn't need to run if this happens. 
Something like:

  if (_value == -1) {
       _value = get_from_cache();
  }
  if (_value == -1) { // didn't get it from the cache
    _value = compute_value();
  }

So basically to delineate the caching logic from the normal path. Does it make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061875051

From iklam at openjdk.org  Sun Apr 27 00:54:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 27 Apr 2025 00:54:47 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <__a0S14OZpuwaQX6jFAlJhZJy2fZ9flb_1LW9gUD_sI=.b2b7851a-0aed-421b-9755-89fc63e404da@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <__a0S14OZpuwaQX6jFAlJhZJy2fZ9flb_1LW9gUD_sI=.b2b7851a-0aed-421b-9755-89fc63e404da@github.com>
Message-ID: <Ge4mXJjDpImoH2ymznE1ANBZqfvUWGDU2xLr28pacTA=.64308ee0-d239-4afe-ad16-17f6fcbdb9a2@github.com>

On Sat, 26 Apr 2025 23:35:01 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 30:
>> 
>>> 28:  * @requires vm.cds
>>> 29:  * @comment work around JDK-8345635
>>> 30:  * @requires !vm.jvmci.enabled
>> 
>> Consider adding:
>> 
>>  * @requires vm.cds.supports.aot.class.linking
>>  * @requires vm.flagless
>
> Could you please explain why? @iklam, what do you think?

I think it's OK to test without these two additional flags. This will make sure that the two diagnostic flags don't have any bad side effect even if AOT class linking is disabled (due to flags like -XX:+UseZGC).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061892882

From iklam at openjdk.org  Sun Apr 27 01:06:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 27 Apr 2025 01:06:00 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <bp9qLzafolLsziyaNhCq_icOAkUvttHMBfLJ-oAQJqc=.19b39f9f-9547-43e7-9c39-18d25f4fb06a@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <bp9qLzafolLsziyaNhCq_icOAkUvttHMBfLJ-oAQJqc=.19b39f9f-9547-43e7-9c39-18d25f4fb06a@github.com>
Message-ID: <D6JCm_Phwb8NwRMMxnPPXqdPr-O1G2WcSccotW7VN34=.62685892-9768-4635-b1e3-938fb2cd8d0c@github.com>

On Sun, 27 Apr 2025 00:02:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/cds/dumpAllocStats.hpp line 151:
>> 
>>> 149:   }
>>> 150: 
>>> 151:   void record_dynamic_proxy_class() {
>> 
>> This is not called. This code seems not related.
>
> True. @iklam, this came with a change you wanted me to take. Ok to cut this out?

Yes, this part is not needed. AOT dynamic proxy classes are only supported in the Leyden repo.

>> src/hotspot/share/oops/methodData.cpp line 1296:
>> 
>>> 1294: 
>>> 1295: MethodData::MethodData() {
>>> 1296:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");
>> 
>> 1. Should its code be guarded by `#if INCLUDE_CDS`?
>> 2. Comment where/how it is used.
>> 3. Is it used in all phases or only during TRAINING and ASSEMBLY?
>> 4. Can you add query methods into `CDSConfig` which you can call here and in other places?:
>> 
>>  is_dumping_training_data()
>>  is_using_training_data()
>
> I think those are used for CDS serialization/deserialization, right, @iklam?

This constructor is used by cppVtables.cpp to calculate the size of the vtables for MethodData, and also for finding the address of the vtable of  MethodData. All types in `CPP_VTABLE_TYPES_DO` must have such an empty constructor. E.g., `InstanceKlass::InstanceKlass()`.

We have not been very consistent with comments around these constructors, but I think we can do this:


#if INCLUDE_CDS
MethodData::MethodData() {
  // Used by cppVtables.cpp only
  assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");
}
#endif


This method is called even if we are not dumping training data. The vtables of all types in `CPP_VTABLE_TYPES_DO` are unconditionally computed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061901400
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061898996

From kvn at openjdk.org  Sun Apr 27 01:14:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 01:14:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <Ge4mXJjDpImoH2ymznE1ANBZqfvUWGDU2xLr28pacTA=.64308ee0-d239-4afe-ad16-17f6fcbdb9a2@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <__a0S14OZpuwaQX6jFAlJhZJy2fZ9flb_1LW9gUD_sI=.b2b7851a-0aed-421b-9755-89fc63e404da@github.com>
 <Ge4mXJjDpImoH2ymznE1ANBZqfvUWGDU2xLr28pacTA=.64308ee0-d239-4afe-ad16-17f6fcbdb9a2@github.com>
Message-ID: <RfTcti-0qEBWAL6KOqBeJI1SsviuwdECfO6zABqmUI0=.ec86305a-f424-4afc-b4a3-104146cb5240@github.com>

On Sun, 27 Apr 2025 00:52:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Could you please explain why? @iklam, what do you think?
>
> I think it's OK to test without these two additional flags. This will make sure that the two diagnostic flags don't have any bad side effect even if AOT class linking is disabled (due to flags like -XX:+UseZGC).

I see them in `aotClassLinking/AOTClassLinkingVMOptions.java` test.
@veresov please, add link to your mach5 testing to JBS. And add to description what tests you already ran.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061907156

From kvn at openjdk.org  Sun Apr 27 01:19:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 01:19:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <OoJZKZbihUQBUDK85cTK16sQQUtcAbdY-R5sntQ8zaQ=.9f20e0b4-c2ed-440a-858e-4486e4c0acc2@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <OoJZKZbihUQBUDK85cTK16sQQUtcAbdY-R5sntQ8zaQ=.9f20e0b4-c2ed-440a-858e-4486e4c0acc2@github.com>
Message-ID: <PldUCKo1RdxtOCfhei3_LXO8A87wWRZWQqSfsLDtTpk=.b2b4fc88-bb6b-4676-a807-a17473d5adb6@github.com>

On Sun, 27 Apr 2025 00:24:31 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/ci/ciInstanceKlass.hpp line 47:
>> 
>>> 45:   friend class ciField;
>>> 46:   friend class ciReplay;
>>> 47:   friend class CompileTrainingData;
>> 
>> Not referenced here
>
> It allows `CompileTrainingData` to peek into the `ciInstanceKlass` internals. We need the klass ptr specially.

I missed that it is "friend" declaration.

>> src/hotspot/share/ci/ciMethodData.cpp line 71:
>> 
>>> 69: 
>>> 70:   bool is_live(Method* m) {
>>> 71:     Klass* holder = m->method_holder();
>> 
>> Changes in this file seems not related and can be pushed/tested separately. If they are related - there should be condition for additional checks.
>
> You mean you want these checks to be done only if `TrainingData::have_data() == true` ?

Yes, if it is related. Otherwise you may change default behavior when Leyden code is not used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061910254
PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061908809

From kvn at openjdk.org  Sun Apr 27 01:23:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 01:23:52 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <cj3ZqriTDE0d_q7KaYaIdyWJe2kVAulA_uUR2NBE3Xw=.9819452b-44d3-47b1-b9ea-71e26c45dc52@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <cj3ZqriTDE0d_q7KaYaIdyWJe2kVAulA_uUR2NBE3Xw=.9819452b-44d3-47b1-b9ea-71e26c45dc52@github.com>
Message-ID: <FMnuiOV9gJFU3Yoe85M3GK5eZVW1Eu2ZM5iDXjvJPMM=.a8d91646-4173-4b23-a301-eff64c2826c4@github.com>

On Sat, 26 Apr 2025 23:58:04 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/oops/trainingData.cpp line 76:
>> 
>>> 74: 
>>> 75: static void verify_archived_entry(TrainingData* td, const TrainingData::Key* k) {
>>> 76:   guarantee(TrainingData::Key::can_compute_cds_hash(k), "");
>> 
>> Should we gracefully disable using TD instead of crashing VM?
>
> But this is a verification code. That seems to be the usual strategy, is it not?

I thought if we can not use AOT cache we issue warning and continue execution without it.
Unless you are checking for damaged AOT cache which may affect execution without it.

@iklam  what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061910742

From iveresov at openjdk.org  Sun Apr 27 01:39:55 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 01:39:55 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <FMnuiOV9gJFU3Yoe85M3GK5eZVW1Eu2ZM5iDXjvJPMM=.a8d91646-4173-4b23-a301-eff64c2826c4@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <cj3ZqriTDE0d_q7KaYaIdyWJe2kVAulA_uUR2NBE3Xw=.9819452b-44d3-47b1-b9ea-71e26c45dc52@github.com>
 <FMnuiOV9gJFU3Yoe85M3GK5eZVW1Eu2ZM5iDXjvJPMM=.a8d91646-4173-4b23-a301-eff64c2826c4@github.com>
Message-ID: <G6q9qIdvkUbZ2hH-xYRCci4OMelpDiwEu-pXqdP6MMA=.6531cc49-a3d4-4f90-b29b-bee61a6cb531@github.com>

On Sun, 27 Apr 2025 01:20:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> But this is a verification code. That seems to be the usual strategy, is it not?
>
> I thought if we can not use AOT cache we issue warning and continue execution without it.
> Unless you are checking for damaged AOT cache which may affect execution without it.
> 
> @iklam  what do you think?

But this runs only with `-XX:+VerifyTrainingData`. It's a testing mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061918596

From iveresov at openjdk.org  Sun Apr 27 01:51:46 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 01:51:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <2ks6GsBxC4Ig0uyg6ufSmzxbU4pvbYcnRWF2IuB0-ac=.954c69b1-e8f3-4e69-abd3-0147ba798471@github.com>

On Sat, 26 Apr 2025 21:30:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> src/hotspot/share/oops/methodData.cpp line 1296:
> 
>> 1294: 
>> 1295: MethodData::MethodData() {
>> 1296:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");
> 
> 1. Should its code be guarded by `#if INCLUDE_CDS`?
> 2. Comment where/how it is used.
> 3. Is it used in all phases or only during TRAINING and ASSEMBLY?
> 4. Can you add query methods into `CDSConfig` which you can call here and in other places?:
> 
>  is_dumping_training_data()
>  is_using_training_data()

@vnkozlov Are you ok with Ioi's code change proposal?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061936106

From kvn at openjdk.org  Sun Apr 27 01:59:45 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 01:59:45 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <G6q9qIdvkUbZ2hH-xYRCci4OMelpDiwEu-pXqdP6MMA=.6531cc49-a3d4-4f90-b29b-bee61a6cb531@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <cj3ZqriTDE0d_q7KaYaIdyWJe2kVAulA_uUR2NBE3Xw=.9819452b-44d3-47b1-b9ea-71e26c45dc52@github.com>
 <FMnuiOV9gJFU3Yoe85M3GK5eZVW1Eu2ZM5iDXjvJPMM=.a8d91646-4173-4b23-a301-eff64c2826c4@github.com>
 <G6q9qIdvkUbZ2hH-xYRCci4OMelpDiwEu-pXqdP6MMA=.6531cc49-a3d4-4f90-b29b-bee61a6cb531@github.com>
Message-ID: <rL6LoWoHS_keU3m6ZQfRBoIWRTcj6P80FNOWXvrkiy4=.a4064c6d-2012-4d68-8608-e38bba5c0134@github.com>

On Sun, 27 Apr 2025 01:37:33 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> I thought if we can not use AOT cache we issue warning and continue execution without it.
>> Unless you are checking for damaged AOT cache which may affect execution without it.
>> 
>> @iklam  what do you think?
>
> But this runs only with `-XX:+VerifyTrainingData`. It's a testing mode.

I missed that. Okay then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061939418

From kvn at openjdk.org  Sun Apr 27 02:03:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 02:03:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <2ks6GsBxC4Ig0uyg6ufSmzxbU4pvbYcnRWF2IuB0-ac=.954c69b1-e8f3-4e69-abd3-0147ba798471@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <2ks6GsBxC4Ig0uyg6ufSmzxbU4pvbYcnRWF2IuB0-ac=.954c69b1-e8f3-4e69-abd3-0147ba798471@github.com>
Message-ID: <_unPFSSYWqe0ldilT96MjUkRFTkiPsYhWkLvWNPj0Ek=.1745d82b-22e3-4fbe-9b46-6d0b3aa177f0@github.com>

On Sun, 27 Apr 2025 01:49:20 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/oops/methodData.cpp line 1296:
>> 
>>> 1294: 
>>> 1295: MethodData::MethodData() {
>>> 1296:   assert(CDSConfig::is_dumping_static_archive() || UseSharedSpaces, "only for CDS");
>> 
>> 1. Should its code be guarded by `#if INCLUDE_CDS`?
>> 2. Comment where/how it is used.
>> 3. Is it used in all phases or only during TRAINING and ASSEMBLY?
>> 4. Can you add query methods into `CDSConfig` which you can call here and in other places?:
>> 
>>  is_dumping_training_data()
>>  is_using_training_data()
>
> @vnkozlov Are you ok with Ioi's code change proposal?

Yes, I am ok. I assume you will change accordingly all other similar empty constructors in your code: `MethodCounters()` and `*TrainingData()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061941118

From iklam at openjdk.org  Sun Apr 27 02:22:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 27 Apr 2025 02:22:56 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <RfTcti-0qEBWAL6KOqBeJI1SsviuwdECfO6zABqmUI0=.ec86305a-f424-4afc-b4a3-104146cb5240@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <__a0S14OZpuwaQX6jFAlJhZJy2fZ9flb_1LW9gUD_sI=.b2b7851a-0aed-421b-9755-89fc63e404da@github.com>
 <Ge4mXJjDpImoH2ymznE1ANBZqfvUWGDU2xLr28pacTA=.64308ee0-d239-4afe-ad16-17f6fcbdb9a2@github.com>
 <RfTcti-0qEBWAL6KOqBeJI1SsviuwdECfO6zABqmUI0=.ec86305a-f424-4afc-b4a3-104146cb5240@github.com>
Message-ID: <S_ZAYMBXJ0DmWdn8gA3xEzt5edydxRRiI4xL0NapOlk=.6869b344-da2b-49f9-b982-391e4e49bb9e@github.com>

On Sun, 27 Apr 2025 01:11:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I think it's OK to test without these two additional flags. This will make sure that the two diagnostic flags don't have any bad side effect even if AOT class linking is disabled (due to flags like -XX:+UseZGC).
>
> I see them in `aotClassLinking/AOTClassLinkingVMOptions.java` test.
> @veresov please, add link to your mach5 testing to JBS. And add to description what tests you already ran.

OK, let's add those two `@requires` to be consistent with other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2061952289

From iveresov at openjdk.org  Sun Apr 27 05:20:46 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Sun, 27 Apr 2025 05:20:46 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling
In-Reply-To: <_unPFSSYWqe0ldilT96MjUkRFTkiPsYhWkLvWNPj0Ek=.1745d82b-22e3-4fbe-9b46-6d0b3aa177f0@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <2ks6GsBxC4Ig0uyg6ufSmzxbU4pvbYcnRWF2IuB0-ac=.954c69b1-e8f3-4e69-abd3-0147ba798471@github.com>
 <_unPFSSYWqe0ldilT96MjUkRFTkiPsYhWkLvWNPj0Ek=.1745d82b-22e3-4fbe-9b46-6d0b3aa177f0@github.com>
Message-ID: <Hcru8I9BVKGZqrXwuftl62dINvDsWyCH1TfhfqgMVsE=.f02a9ee0-9128-4fce-b52a-16f6d20de796@github.com>

On Sun, 27 Apr 2025 02:00:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov Are you ok with Ioi's code change proposal?
>
> Yes, I am ok. I assume you will change accordingly all other similar empty constructors in your code: `MethodCounters()` and `*TrainingData()`.

Yes, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2062292557

From mitani at daisuke2.com  Sun Apr 27 06:00:02 2025
From: mitani at daisuke2.com (mitani at daisuke2.com)
Date: Sun, 27 Apr 2025 15:00:02 +0900
Subject: About compiling on macOS
Message-ID: <64A5EE75-AE8B-4127-8567-EA8A73CAA1EC@daisuke2.com>

I have just compiled in the master branch. As a result, I am struggling with the following compilation errors.

Configuration summary:
* Name:           macosx-aarch64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
-n * JVM features:   
-n server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc' 

* OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
* Version string: 25-internal-adhoc.mitani.jdk (25-internal)
* Source date:    1745733212 (2025-04-27T05:53:32Z)

Tools summary:
* Boot JDK:       openjdk version "24.0.1" 2025-04-15 OpenJDK Runtime Environment Corretto-24.0.1.9.1 (build 24.0.1+9-FR) OpenJDK 64-Bit Server VM Corretto-24.0.1.9.1 (build 24.0.1+9-FR, mixed mode, sharing) (at /Library/Java/JavaVirtualMachines/amazon-corretto-24.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM from Xcode 16.3)
* Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk
* C Compiler:     Version 17.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 17.0.0 (at /usr/bin/clang++)



git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
127 | AudioDeviceID devices[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
126 | int count = size/sizeof(AudioDeviceID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
151 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
150 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
483 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
458 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
775 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
772 | PortControl *control = (PortControl *)controlIDV;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
824 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
818 | PortControl *control = (PortControl *)controlIDV;
| ^
7 errors generated.
make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [java.desktop-libs] Error 2
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
Stopping javac server

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
127 | AudioDeviceID devices[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
126 | int count = size/sizeof(AudioDeviceID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
151 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
150 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
... (rest of output omitted)

* All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
make: *** [default] Error 2
make
Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
152 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
151 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
484 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
459 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
528 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
530 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
776 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:773:18: note: declared here
773 | PortControl *control = (PortControl *)controlIDV;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
825 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:819:18: note: declared here
819 | PortControl *control = (PortControl *)controlIDV;
| ^
6 errors generated.
make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
make[3]: *** Waiting for unfinished jobs....
ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
make[2]: *** [java.desktop-libs] Error 2

ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
152 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
151 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
484 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
459 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
... (rest of output omitted)

* All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
make: *** [default] Error 2
make
Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
485 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
460 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
531 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
777 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:774:18: note: declared here
774 | PortControl *control = (PortControl *)controlIDV;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
826 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:820:18: note: declared here
820 | PortControl *control = (PortControl *)controlIDV;
| ^
7 errors generated.
make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [java.desktop-libs] Error 2

ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
485 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
460 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
... (rest of output omitted)

* All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
make: *** [default] Error 2
git reset --hard
HEAD is now at 898d4798003 8355077: Compiler error at splashscreen_gif.c due to unterminated string initialization
make
Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
127 | AudioDeviceID devices[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
126 | int count = size/sizeof(AudioDeviceID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
151 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
150 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
483 | AudioObjectID controlIDs[mixer->deviceControlCount];
| ^~~~~~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
458 | PortMixer *mixer = (PortMixer *)id;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
| ^~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
775 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
772 | PortControl *control = (PortControl *)controlIDV;
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
824 | Float32 subVolumes[control->controlCount];
| ^~~~~~~~~~~~~~~~~~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
818 | PortControl *control = (PortControl *)controlIDV;
| ^
7 errors generated.
make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [java.desktop-libs] Error 2

ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
127 | AudioDeviceID devices[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
126 | int count = size/sizeof(AudioDeviceID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
151 | AudioObjectID controlIDs[count];
| ^~~~~
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
150 | int count = size / sizeof(AudioObjectID);
| ^
git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
... (rest of output omitted)

* All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
make: *** [default] Error 2

From tanksherman27 at gmail.com  Sun Apr 27 07:17:41 2025
From: tanksherman27 at gmail.com (Julian Waters)
Date: Sun, 27 Apr 2025 15:17:41 +0800
Subject: About compiling on macOS
Message-ID: <CAP2b4GPgueOdxYwsf5DUGKmx7QHp3LhPd+DEkHMR9_-oKHysjw@mail.gmail.com>

Hi,

The errors seem like they can be fixed by dynamically allocating the
arrays rather than trying to use a non constant expression to set the
array size. As the compiler says, variable length arrays are not
allowed in C++. I unfortunately don't have a Mac to test this fix on
however. Perhaps a newer clang version made the variable length array
warning stronger, which causes the compile failure.

best regards,
Julian

From jai.forums2013 at gmail.com  Sun Apr 27 07:34:23 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 27 Apr 2025 13:04:23 +0530
Subject: About compiling on macOS
In-Reply-To: <64A5EE75-AE8B-4127-8567-EA8A73CAA1EC@daisuke2.com>
References: <64A5EE75-AE8B-4127-8567-EA8A73CAA1EC@daisuke2.com>
Message-ID: <cad47d97-fefe-419e-bf96-d1dcb151a09b@gmail.com>

A previous report too suggests that the JDK build fails (due to compiler 
warnings) when using 16.3 of Xcode on macos. Do you have access to a 
15.4 version of Xcode instead? If so, then you can use 
"--with-xcode-path" during configure to point to that installation of 
Xcode and build the JDK (more details in the documentation here 
https://github.com/openjdk/jdk/blob/master/doc/building.md#apple-xcode). 
I believe that version should be fine.

If you cannot use any other XCode other than 16.3, then you can build 
the JDK by using the "--disable-warnings-as-errors" configure option 
(more details here 
https://github.com/openjdk/jdk/blob/master/doc/building.md#problems-with-the-build-environment). 
Another user has reported previously that this option allowed them to 
successfully build with XCode 16.3.

Long term, the warnings from that part of the code will have to be 
investigated in the JDK.

-Jaikiran

On 27/04/25 11:30 am, mitani at daisuke2.com wrote:
> I have just compiled in the master branch. As a result, I am struggling with the following compilation errors.
>
> Configuration summary:
> * Name:           macosx-aarch64-server-release
> * Debug level:    release
> * HS debug level: product
> * JVM variants:   server
> -n * JVM features:
> -n server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
>
> * OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
> * Version string: 25-internal-adhoc.mitani.jdk (25-internal)
> * Source date:    1745733212 (2025-04-27T05:53:32Z)
>
> Tools summary:
> * Boot JDK:       openjdk version "24.0.1" 2025-04-15 OpenJDK Runtime Environment Corretto-24.0.1.9.1 (build 24.0.1+9-FR) OpenJDK 64-Bit Server VM Corretto-24.0.1.9.1 (build 24.0.1+9-FR, mixed mode, sharing) (at /Library/Java/JavaVirtualMachines/amazon-corretto-24.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM from Xcode 16.3)
> * Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk
> * C Compiler:     Version 17.0.0 (at /usr/bin/clang)
> * C++ Compiler:   Version 17.0.0 (at /usr/bin/clang++)
>
>
>
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 127 | AudioDeviceID devices[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
> 126 | int count = size/sizeof(AudioDeviceID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 151 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
> 150 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
> 458 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 775 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
> 772 | PortControl *control = (PortControl *)controlIDV;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 824 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
> 818 | PortControl *control = (PortControl *)controlIDV;
> | ^
> 7 errors generated.
> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.desktop-libs] Error 2
> make[2]: *** Waiting for unfinished jobs....
>
> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
> Stopping javac server
>
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 127 | AudioDeviceID devices[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
> 126 | int count = size/sizeof(AudioDeviceID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 151 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
> 150 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> ... (rest of output omitted)
>
> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> make: *** [default] Error 2
> make
> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 152 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
> 151 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
> 459 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 528 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
> 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 530 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
> 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 776 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:773:18: note: declared here
> 773 | PortControl *control = (PortControl *)controlIDV;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 825 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:819:18: note: declared here
> 819 | PortControl *control = (PortControl *)controlIDV;
> | ^
> 6 errors generated.
> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
> make[2]: *** [java.desktop-libs] Error 2
>
> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 152 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
> 151 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
> 459 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> ... (rest of output omitted)
>
> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> make: *** [default] Error 2
> make
> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
> 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
> 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
> 460 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
> 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 531 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
> 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 777 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:774:18: note: declared here
> 774 | PortControl *control = (PortControl *)controlIDV;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 826 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:820:18: note: declared here
> 820 | PortControl *control = (PortControl *)controlIDV;
> | ^
> 7 errors generated.
> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.desktop-libs] Error 2
>
> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
> 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
> 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
> 460 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
> ... (rest of output omitted)
>
> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> make: *** [default] Error 2
> git reset --hard
> HEAD is now at 898d4798003 8355077: Compiler error at splashscreen_gif.c due to unterminated string initialization
> make
> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 127 | AudioDeviceID devices[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
> 126 | int count = size/sizeof(AudioDeviceID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 151 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
> 150 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
> 458 | PortMixer *mixer = (PortMixer *)id;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
> | ^~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 775 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
> 772 | PortControl *control = (PortControl *)controlIDV;
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 824 | Float32 subVolumes[control->controlCount];
> | ^~~~~~~~~~~~~~~~~~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
> 818 | PortControl *control = (PortControl *)controlIDV;
> | ^
> 7 errors generated.
> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.desktop-libs] Error 2
>
> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 127 | AudioDeviceID devices[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
> 126 | int count = size/sizeof(AudioDeviceID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> 151 | AudioObjectID controlIDs[count];
> | ^~~~~
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
> 150 | int count = size / sizeof(AudioObjectID);
> | ^
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
> ... (rest of output omitted)
>
> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> make: *** [default] Error 2

From mitani at daisuke2.com  Sun Apr 27 11:02:28 2025
From: mitani at daisuke2.com (mitani at daisuke2.com)
Date: Sun, 27 Apr 2025 20:02:28 +0900
Subject: About compiling on macOS
In-Reply-To: <cad47d97-fefe-419e-bf96-d1dcb151a09b@gmail.com>
References: <64A5EE75-AE8B-4127-8567-EA8A73CAA1EC@daisuke2.com>
 <cad47d97-fefe-419e-bf96-d1dcb151a09b@gmail.com>
Message-ID: <2BB544DE-AA13-4CEC-9EDA-73774D51B598@daisuke2.com>

Hi Jaikiran

> If you cannot use any other XCode other than 16.3, then you can build the JDK by using the "--disable-warnings-as-errors" configure option (more details here https://github.com/openjdk/jdk/blob/master/doc/building.md#problems-with-the-build-environment). Another user has reported previously that this option allowed them to successfully build with XCode 16.3.
I was able to successfully compile using this method. Thank you.

> 2025/04/27 16:34?Jaikiran Pai <jai.forums2013 at gmail.com>????:
> 
> A previous report too suggests that the JDK build fails (due to compiler warnings) when using 16.3 of Xcode on macos. Do you have access to a 15.4 version of Xcode instead? If so, then you can use "--with-xcode-path" during configure to point to that installation of Xcode and build the JDK (more details in the documentation here https://github.com/openjdk/jdk/blob/master/doc/building.md#apple-xcode). I believe that version should be fine.
> 
> If you cannot use any other XCode other than 16.3, then you can build the JDK by using the "--disable-warnings-as-errors" configure option (more details here https://github.com/openjdk/jdk/blob/master/doc/building.md#problems-with-the-build-environment). Another user has reported previously that this option allowed them to successfully build with XCode 16.3.
> 
> Long term, the warnings from that part of the code will have to be investigated in the JDK.
> 
> -Jaikiran
> 
> On 27/04/25 11:30 am, mitani at daisuke2.com wrote:
>> I have just compiled in the master branch. As a result, I am struggling with the following compilation errors.
>> 
>> Configuration summary:
>> * Name:           macosx-aarch64-server-release
>> * Debug level:    release
>> * HS debug level: product
>> * JVM variants:   server
>> -n * JVM features:
>> -n server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
>> 
>> * OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64
>> * Version string: 25-internal-adhoc.mitani.jdk (25-internal)
>> * Source date:    1745733212 (2025-04-27T05:53:32Z)
>> 
>> Tools summary:
>> * Boot JDK:       openjdk version "24.0.1" 2025-04-15 OpenJDK Runtime Environment Corretto-24.0.1.9.1 (build 24.0.1+9-FR) OpenJDK 64-Bit Server VM Corretto-24.0.1.9.1 (build 24.0.1+9-FR, mixed mode, sharing) (at /Library/Java/JavaVirtualMachines/amazon-corretto-24.jdk/Contents/Home)
>> * Toolchain:      clang (clang/LLVM from Xcode 16.3)
>> * Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk
>> * C Compiler:     Version 17.0.0 (at /usr/bin/clang)
>> * C++ Compiler:   Version 17.0.0 (at /usr/bin/clang++)
>> 
>> 
>> 
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 127 | AudioDeviceID devices[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>> 126 | int count = size/sizeof(AudioDeviceID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 151 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
>> 150 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
>> 458 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
>> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
>> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 775 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
>> 772 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 824 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
>> 818 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> 7 errors generated.
>> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [java.desktop-libs] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> 
>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>> Stopping javac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 127 | AudioDeviceID devices[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>> 126 | int count = size/sizeof(AudioDeviceID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 151 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
>> 150 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> ... (rest of output omitted)
>> 
>> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
>> make: *** [default] Error 2
>> make
>> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
>> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 152 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
>> 151 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
>> 459 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 528 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
>> 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 530 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9: note: declared here
>> 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 776 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:773:18: note: declared here
>> 773 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 825 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:819:18: note: declared here
>> 819 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> 6 errors generated.
>> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
>> make[2]: *** [java.desktop-libs] Error 2
>> 
>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 152 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21: note: declared here
>> 151 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16: note: declared here
>> 459 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> ... (rest of output omitted)
>> 
>> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
>> make: *** [default] Error 2
>> make
>> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
>> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
>> 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
>> 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
>> 460 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
>> 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 531 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9: note: declared here
>> 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 777 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:774:18: note: declared here
>> 774 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 826 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:820:18: note: declared here
>> 820 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> 7 errors generated.
>> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [java.desktop-libs] Error 2
>> 
>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87: error: use of undeclared identifier 'controlIDs'
>> 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID), &controlIDs, 1);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74: error: use of undeclared identifier 'controlIDs'
>> 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16: note: declared here
>> 460 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
>> ... (rest of output omitted)
>> 
>> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
>> make: *** [default] Error 2
>> git reset --hard
>> HEAD is now at 898d4798003 8355077: Compiler error at splashscreen_gif.c due to unterminated string initialization
>> make
>> Building target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release'
>> Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 127 | AudioDeviceID devices[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>> 126 | int count = size/sizeof(AudioDeviceID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 151 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
>> 150 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: note: read of non-constexpr variable 'mixer' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16: note: declared here
>> 458 | PortMixer *mixer = (PortMixer *)id;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
>> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master channel
>> | ^~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32: note: read of non-const variable 'totalChannels' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9: note: declared here
>> 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope == kAudioDevicePropertyScopeOutput ? 1 : 0);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 775 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18: note: declared here
>> 772 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 824 | Float32 subVolumes[control->controlCount];
>> | ^~~~~~~~~~~~~~~~~~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24: note: read of non-constexpr variable 'control' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18: note: declared here
>> 818 | PortControl *control = (PortControl *)controlIDV;
>> | ^
>> 7 errors generated.
>> make[3]: *** [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o] Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [java.desktop-libs] Error 2
>> 
>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-aarch64-server-release' (exit code 2)
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 127 | AudioDeviceID devices[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21: note: declared here
>> 126 | int count = size/sizeof(AudioDeviceID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> 151 | AudioObjectID controlIDs[count];
>> | ^~~~~
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42: note: read of non-const variable 'count' is not allowed in a constant expression
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21: note: declared here
>> 150 | int count = size / sizeof(AudioObjectID);
>> | ^
>> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
>> ... (rest of output omitted)
>> 
>> * All command lines available in git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
>> make: *** [default] Error 2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250427/c7c14784/attachment-0001.htm>

From jwaters at openjdk.org  Sun Apr 27 15:10:45 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 27 Apr 2025 15:10:45 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <o1f3SIzBzkjqxKoG76sTKDEjJBnTVWuYNkKEtSCUwPQ=.cb3dd755-cc12-42ab-9772-eba15625ebf5@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
 <o1f3SIzBzkjqxKoG76sTKDEjJBnTVWuYNkKEtSCUwPQ=.cb3dd755-cc12-42ab-9772-eba15625ebf5@github.com>
Message-ID: <gJun1jZs83q0Cnzg17v8bdKFoIArSC88xqo8TPl-X5A=.c269e522-d8b9-46fa-857a-2b0c2ac8d869@github.com>

On Fri, 25 Apr 2025 07:26:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig
>
> .editorconfig line 10:
> 
>> 8: 
>> 9: [src/hotspot/**.{cpp,hpp,h}]
>> 10: indent_style = space
> 
> Just wondering - will the new src/hotspot block inherit the trim_trailing_whitespace setting from the top-level [*] block?

>From documentation that I checked it should, but I'll test it just to be sure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24714#discussion_r2062652131

From kvn at openjdk.org  Sun Apr 27 21:52:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 21:52:43 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v8]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

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

  Downgraded UL as asked. Added synchronization to C strings caching.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/91c37dad..2eb7e80d

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

  Stats: 135 lines in 10 files changed: 53 ins; 18 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

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

From kvn at openjdk.org  Sun Apr 27 21:55:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 21:55:48 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
Message-ID: <vyMOsOIMgyQCTzeYbvzgr00vO4XrJ9qrGTReYO7u1nc=.0414ac3c-ac37-45ba-a634-619218112609@github.com>

On Tue, 22 Apr 2025 23:05:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix message

Downgraded UL - minimum output for `log_info`.
Added new lock `AOTCodeCStrings_lock` to synchronize C strings caching - several compiler threads may add C strings simultaneously.
Also don't record c strings from C2 scratch buffer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2833656527

From kvn at openjdk.org  Sun Apr 27 21:55:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 21:55:49 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v8]
In-Reply-To: <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>
Message-ID: <yiCavh11KDmKWIVClopYzXoFIgftyiI67MqBactDUwU=.0bfc7aaa-5277-41b6-b274-ae9326314e46@github.com>

On Sun, 27 Apr 2025 21:52:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Downgraded UL as asked. Added synchronization to C strings caching.

I repeated testing again - it passed.

@iwanowww, @ashu-mehra please review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2833656967

From kvn at openjdk.org  Sun Apr 27 22:22:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 27 Apr 2025 22:22:02 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v9]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' into JDK-8350209
 - Downgraded UL as asked. Added synchronization to C strings caching.
 - Fix message
 - Generate far jumps for AOT code on AArch64
 - remove _enabled suffix
 - Add sanity test for AOTAdapterCaching flag
 - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
 - Removed unused AOTCodeSection class
 - 8350209: Preserve adapters in AOT cache

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

Changes: https://git.openjdk.org/jdk/pull/24740/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=08
  Stats: 3306 lines in 51 files changed: 2837 ins; 200 del; 269 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

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

From liach at openjdk.org  Mon Apr 28 01:49:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 01:49:34 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
Message-ID: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>

Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.

With this patch, we can now emulate this ASM pattern easily:


// ASM
ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
cv.visitXxx(); // write elements through the delegate

// ClassFile API
cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
    // write elements through delegate
}));


Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

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

Commit messages:
 - 8355658: Allow transforms to run on elements generated by a builder

Changes: https://git.openjdk.org/jdk/pull/24908/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355658
  Stats: 301 lines in 11 files changed: 206 ins; 26 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/24908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24908/head:pull/24908

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

From iveresov at openjdk.org  Mon Apr 28 04:22:32 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 28 Apr 2025 04:22:32 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v2]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <VfUM_BOoHzt6hPfealQvfnupzcnPRflISQmB55FqvT0=.620892a5-63f1-4f19-aa7d-3c1433873e6f@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the workaround of setting AOTRecordTraining during assembly
 - Address some of the review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/3ec132e7..fea6171e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=00-01

  Stats: 96 lines in 9 files changed: 30 ins; 49 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From amitkumar at openjdk.org  Mon Apr 28 04:22:48 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 28 Apr 2025 04:22:48 GMT
Subject: RFR: 8355570: [s390x] Update -march to z13 generation
In-Reply-To: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
References: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
Message-ID: <uynZy04nb5q0-wP-tRIzjW5MDYVOhTEruYaGj5Wclf4=.efc0ca23-56c7-4b55-9626-8ca0de3517ad@github.com>

On Fri, 25 Apr 2025 06:24:31 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> updated march level from z10 to z13.
> 
> Testing: tier1 (fastdebug-vm)

That's weird, the build for s390x is failing in cross compile: 


=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_libgtest_objs_gmock-all.o:
In file included from /home/runner/work/jdk/jdk/gtest/googlemock/src/gmock-all.cc:46:
In function ?void testing::internal::InitGoogleMockImpl(int*, CharType**) [with CharType = char]?,
    inlined from ?void testing::internal::InitGoogleMockImpl(int*, CharType**) [with CharType = char]? at /home/runner/work/jdk/jdk/gtest/googlemock/src/gmock.cc:145:6,
    inlined from ?void testing::InitGoogleMock()? at /home/runner/work/jdk/jdk/gtest/googlemock/src/gmock.cc:222:31:
/home/runner/work/jdk/jdk/gtest/googlemock/src/gmock.cc:177:17: error: ?void* __builtin_memmove(void*, const void*, long unsigned int)? writing between 8 and 34359738368 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  177 |         argv[j] = argv[j + 1];
      |         ~~~~~~~~^~~~~~~
cc1plus: all warnings being treated as errors
* For target hotspot_variant-server_libjvm_objs_jvmtiAgent.o:
In function ?void vm_exit(const JvmtiAgent*, const char*, const char*)?,
    inlined from ?void* load_agent_from_absolute_path(JvmtiAgent*, bool)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:281:12,
    inlined from ?void* load_library(JvmtiAgent*, bool)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:311:67,
    inlined from ?jint (* lookup_On_Load_entry_point(JvmtiAgent*, const char*, bool))(JavaVM*, char*, void*)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:326:41,
    inlined from ?jint (* lookup_JVM_OnLoad_entry_point(JvmtiAgent*, bool))(JavaVM*, char*, void*)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:344:36,
    inlined from ?bool invoke_JVM_OnLoad(JvmtiAgent*)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:374:62,
    inlined from ?bool JvmtiAgent::load(outputStream*)? at /home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:620:29:
/home/runner/work/jdk/jdk/src/hotspot/share/prims/jvmtiAgent.cpp:245:154: error: argument 1 null where non-null expected [-Werror=nonnull]
  245 |   const size_t len = strlen(not_found_error_msg) + strlen(agent->name()) + strlen(sub_msg1) + strlen(&ebuf[0]) + 1 + (agent->is_instrument_lib() ? strlen(sub_msg2) : 0);
      |                                                                                                                                                    ~~~~~~^~~~~~~~~~
In file included from /home/runner/work/jdk/jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:37,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:36,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/utilities/align.hpp:31,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/runtime/globals_shared.hpp:28,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/cds/cds_globals.hpp:28,
   ... (rest of output omitted)


I tested on my system and tier1 test were totally fine, Head stream build is not broken for s390x.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2833942833

From liach at openjdk.org  Mon Apr 28 04:33:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 04:33:49 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
References: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
Message-ID: <M_03nynSpM_SgxEYQmdIr_g-1Wp3MYFDASdMyDw3wJ8=.2cec2175-32b9-4e2d-a53d-7f4c76e4130e@github.com>

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Testing: tier 1-3 passed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2833954434

From mcimadamore at openjdk.org  Mon Apr 28 08:35:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Apr 2025 08:35:53 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include <jni.h>'.

Looks good to me -- but also risky. I'd prefer if @JornVernee could also take a look.

The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.

The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.

Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2798483910
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2834427351

From iveresov at openjdk.org  Mon Apr 28 08:48:14 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 28 Apr 2025 08:48:14 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v3]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <l001tWOsh3aymnRy5FrnQBWnkN0q07DgwoY4ACa-6RE=.a07503e0-20a1-4e55-ba1b-5d4b944c387c@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Fix class filtering

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/fea6171e..2a490c66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=01-02

  Stats: 7 lines in 2 files changed: 5 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Mon Apr 28 09:15:28 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 28 Apr 2025 09:15:28 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into pp2
 - Fix class filtering
 - Remove the workaround of setting AOTRecordTraining during assembly
 - Address some of the review comments
 - Merge branch 'master' into pp
 - Add AOTCompileEagerly flag to control compilation after clinit
 - Port 8355334: [leyden] Missing type profile info in archived training data
 - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
 - Use ENABLE_IF macro
 - Missing part of the last commit
 - ... and 22 more: https://git.openjdk.org/jdk/compare/2447b981...7fb7ae62

-------------

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=03
  Stats: 3185 lines in 57 files changed: 2960 ins; 103 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From asotona at openjdk.org  Mon Apr 28 09:33:48 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Apr 2025 09:33:48 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
References: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
Message-ID: <aQKsVQpF0WrzsSxgRugK2XtNZcBeNNtPS1o_p_6_voA=.6c0f2e43-d3fa-44da-9ace-73efdc8c825d@github.com>

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Actual workaround for the above pattern is:

cf.transformClass(cf.parse(cf.build(...)), (clb, cle) -> /*process */, clb -> {
    // write elements through delegate
});

Instead of breaking the actual Class-File API compatibility and introduction of a new complex build&transform pattern
I would rather propose a new API method(s) ``ClassFile::buildToModel``.
However only if there is a strong request to optimize the process (to avoid redundant build/parse spin).

``CodeBuilder::transforming`` was never intended as a general pattern for all elements on all levels. Code building is the only exception providing intermediate transformation. Code building needs to handle situations where the actually built code must be immediately transformed in order to make the code valid to successfully finish the build process. This approach is not necessary on other building levels (class, method or field builder).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2834600671

From ihse at openjdk.org  Mon Apr 28 09:44:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 09:44:48 GMT
Subject: RFR: 8345874: Run make doctor automatically on failed CI builds
 [v2]
In-Reply-To: <n_0zgeGsd28f8aBPJhiIlTyXy3P0grCxiJrhDP6sP5A=.4696f43c-7bc4-426d-b8d4-7eb5f47ceef8@github.com>
References: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>
 <aP_O9sjC7Z4SKP926eonLrqLRHc49tzkwhKBvhAqdrs=.ac8da7ea-e2d2-41c8-b9de-c3923ab1e518@github.com>
 <n_0zgeGsd28f8aBPJhiIlTyXy3P0grCxiJrhDP6sP5A=.4696f43c-7bc4-426d-b8d4-7eb5f47ceef8@github.com>
Message-ID: <EHJHfy_0BMX2PTApqB7mEoZ4Ajo2j9ii4RfUF2TpleU=.be5f2d71-db92-4b21-9378-15d444b25290@github.com>

On Sun, 20 Apr 2025 04:01:31 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into make-doctor-on-ci
>>  - 8345874: Run make doctor automatically on failed CI builds
>
> make/autoconf/spec.gmk.template line 173:
> 
>> 171: 
>> 172: # dev or ci
>> 173: BUILD_ENV := @BUILD_ENV@
> 
> I think the `BUILD_ENV` could be seted in command line also. So, should we update the doc/building.md sync with this change.

What do you mean? This is controlled by the `--with-build-env=[ci|dev]` option. It just needed to be exported from the configure script to the make files.

I am not sure if `--with-build-env` is documented in building.md, but in any case we just list a short selection of options there; the documentation points to `configure --help` to list all currently available options. (It is not feasible to keep the documentation in sync for every possible option.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24485#discussion_r2063304652

From hannesw at openjdk.org  Mon Apr 28 10:06:57 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 28 Apr 2025 10:06:57 GMT
Subject: Integrated: 8348282: Add option for syntax highlighting in javadoc
 snippets
In-Reply-To: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
References: <qroz_24wLJxQsRJ7XGOeKFQLuUIW8mTL9pKzLuozOfg=.212f806a-777c-4a30-96d9-079d2c796bb5@github.com>
Message-ID: <t1lj6xECCXEl8_vyCM-tVxpiTQxIimTEice9YLI0KCg=.1a48ede4-3b96-449c-8a04-43bfd4abe281@github.com>

On Thu, 3 Apr 2025 14:48:58 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to add a `javadoc` option to enable syntax highlighting for code fragments in snippets and  `<pre><code>` tags. The new `--syntax-highlight` option uses the [highlight.js] JavaScript library and supports Java, Properties, XML, HTML and JSON. The option is enabled in the JDK API docs target, [generated output is available here](https://cr.openjdk.org/~hannesw/8348282/api.00/index.html).

This pull request has now been integrated.

Changeset: b0c3485d
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0c3485d6c911898b1ac07eccfe7d2b2668144cc
Stats:     3530 lines in 13 files changed: 3516 ins; 3 del; 11 mod

8348282: Add option for syntax highlighting in javadoc snippets

Reviewed-by: liach, nbenalla, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/24417

From ihse at openjdk.org  Mon Apr 28 10:37:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 10:37:55 GMT
Subject: RFR: 8355235: Clean out old versions from Tools.gmk
In-Reply-To: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
References: <12pzBVW-3j0s52ueLw1hsPYeP_FOlZe8N3VkM2RMWdA=.a39a3b67-1134-4b2a-b7f1-6465fadf09f1@github.com>
Message-ID: <0WT_SupiSpv7_6vUbsp9aZaWf-Hl56abWlGcOXEK0uo=.3df0b806-cefd-46ea-953a-1306f18a67ee@github.com>

On Mon, 21 Apr 2025 22:51:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Traditionally, when upgrading the versions of the components (gcc, binutils, etc.) in Tools.gmk, the old versions/definitions have been preserved. The list is now starting to be on the long side, it's unlikely that anybody would be using anything but the latest/default version, and if they do it is possible to get it from the source/version history.
> 
> Let's clean out the old version information, leaving only the latest/default.
> 
> Testing: tier1, manually built devkits for `x86_64-linux-gnu-to-{x86_64,aarch64,ppc64le,riscv64,s390x}-linux-gnu` and then built the JDK using those devkits.

Going forward, I don't think we even need to save more than a single version in the makefile. If we want older versions, well, that's what git is for.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24784#issuecomment-2834795468

From ihse at openjdk.org  Mon Apr 28 10:59:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 10:59:45 GMT
Subject: RFR: 8354902: Change to Visual Studio 17.13.2 for building on
 Windows at Oracle
In-Reply-To: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
References: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
Message-ID: <CTg7SgTaa70DZxSowZd__qt_gPeadizQ0zvA7K9bJus=.eab1689c-8400-47b5-bf24-ccba308da6fb@github.com>

On Thu, 17 Apr 2025 01:17:50 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.
> 
> Testing: tier1-5

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24707#pullrequestreview-2798900788

From ihse at openjdk.org  Mon Apr 28 11:03:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 11:03:45 GMT
Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle
In-Reply-To: <thFDDcVLix_-gk7TLl464NFx_Ajes-oC4YONSwsgp-0=.66d42c84-e94b-4810-b508-5e86a840a1d3@github.com>
References: <thFDDcVLix_-gk7TLl464NFx_Ajes-oC4YONSwsgp-0=.66d42c84-e94b-4810-b508-5e86a840a1d3@github.com>
Message-ID: <QJjNEFFE2taLMZBI6p8sOVO7K9ICJEdexzAqsbXQvfk=.fe374054-10cc-4e4d-a972-3796ac488def@github.com>

On Thu, 24 Apr 2025 20:55:33 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4.
> 
> Testing: tier1-5

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24862#pullrequestreview-2798912840

From duke at openjdk.org  Mon Apr 28 11:08:21 2025
From: duke at openjdk.org (kuaiwei)
Date: Mon, 28 Apr 2025 11:08:21 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2
Message-ID: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>

The patch fix error when creating devkit on wsl/msys2 .
* Msys2 can be supported like cygwin
* In wsl, it can not test path name in windows format, like `d:/VisualStuio` . The path must be converted as linux style.
* In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell

I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)

-------------

Commit messages:
 - 8355697: Create windows devkit on wsl and msys2

Changes: https://git.openjdk.org/jdk/pull/24916/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355697
  Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24916/head:pull/24916

PR: https://git.openjdk.org/jdk/pull/24916

From mcimadamore at openjdk.org  Mon Apr 28 11:53:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 28 Apr 2025 11:53:47 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
Message-ID: <r64MRcbC2bHeuWWUV__lg-dwavh28Ps4uOKU3l1IY6A=.f0e18a03-8d75-4ce0-9090-cc577c687205@github.com>

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 57:

> 55:             if (!(o instanceof CacheKey other)) return false;
> 56: 
> 57:             return methodType == other.methodType && abi == other.abi && capturedStateMask == other.capturedStateMask

Is this correct? The old code was using `MethodType::equals`, but now we seem to use `==` instead. I suppose the idea is that method types are interned, and their `equals` method is only really meaningful when checking whether a method type with same shape has already been interned?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063500588

From liach at openjdk.org  Mon Apr 28 12:29:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 12:29:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <r64MRcbC2bHeuWWUV__lg-dwavh28Ps4uOKU3l1IY6A=.f0e18a03-8d75-4ce0-9090-cc577c687205@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
 <r64MRcbC2bHeuWWUV__lg-dwavh28Ps4uOKU3l1IY6A=.f0e18a03-8d75-4ce0-9090-cc577c687205@github.com>
Message-ID: <mVNnBL9BArExJ79OP_edKXGGjcxCQC2W5OveLbgRQwI=.c3fa5c2c-7aa3-48c8-8f87-a60140f93c0e@github.com>

On Mon, 28 Apr 2025 11:51:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 57:
> 
>> 55:             if (!(o instanceof CacheKey other)) return false;
>> 56: 
>> 57:             return methodType == other.methodType && abi == other.abi && capturedStateMask == other.capturedStateMask
> 
> Is this correct? The old code was using `MethodType::equals`, but now we seem to use `==` instead. I suppose the idea is that method types are interned, and their `equals` method is only really meaningful when checking whether a method type with same shape has already been interned?

Yep, equals are only used on primordial method types for the intern table. Identity is significant for invokers sharing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063551903

From syan at openjdk.org  Mon Apr 28 12:36:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 28 Apr 2025 12:36:46 GMT
Subject: RFR: 8345874: Run make doctor automatically on failed CI builds
 [v2]
In-Reply-To: <EHJHfy_0BMX2PTApqB7mEoZ4Ajo2j9ii4RfUF2TpleU=.be5f2d71-db92-4b21-9378-15d444b25290@github.com>
References: <p74DuccDIkaOP6c-UphImbOsgbBa04F-mBnlm94zRHQ=.c4702113-c958-41bb-8470-65f8743d1924@github.com>
 <aP_O9sjC7Z4SKP926eonLrqLRHc49tzkwhKBvhAqdrs=.ac8da7ea-e2d2-41c8-b9de-c3923ab1e518@github.com>
 <n_0zgeGsd28f8aBPJhiIlTyXy3P0grCxiJrhDP6sP5A=.4696f43c-7bc4-426d-b8d4-7eb5f47ceef8@github.com>
 <EHJHfy_0BMX2PTApqB7mEoZ4Ajo2j9ii4RfUF2TpleU=.be5f2d71-db92-4b21-9378-15d444b25290@github.com>
Message-ID: <unNhc14LASFS_S0ghSncE_NMKv29GOJN88ZZfyRjSlw=.2e245bd2-63bc-48a1-8fe6-a6e8ef83448d@github.com>

On Mon, 28 Apr 2025 09:41:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/spec.gmk.template line 173:
>> 
>>> 171: 
>>> 172: # dev or ci
>>> 173: BUILD_ENV := @BUILD_ENV@
>> 
>> I think the `BUILD_ENV` could be seted in command line also. So, should we update the doc/building.md sync with this change.
>
> What do you mean? This is controlled by the `--with-build-env=[ci|dev]` option. It just needed to be exported from the configure script to the make files.
> 
> I am not sure if `--with-build-env` is documented in building.md, but in any case we just list a short selection of options there; the documentation points to `configure --help` to list all currently available options. (It is not feasible to keep the documentation in sync for every possible option.)

At first I mistakenly thought that the value of the BUILD_ENV variable was read from the environment variable

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24485#discussion_r2063564104

From jvernee at openjdk.org  Mon Apr 28 13:07:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:07:46 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
Message-ID: <QsdrYOJfCnK8QFDVAJr79nxxV04obwX92GFyNTtj1rE=.9ade70cb-eadc-4eeb-ac8b-ae7504408689@github.com>

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

I remember this wasn't quite as elegant on Windows, but I suppose there is already some solution in place to look up symbols that are statically linked into the same executable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2835178681

From jvernee at openjdk.org  Mon Apr 28 13:24:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:24:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: <N3gqpPLH2w_OJsYgebnwrASA-ReYqToLSbAb6q8yoQ8=.c650c89d-0d4d-4cff-9936-93d2ed7abf5d@github.com>

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include <jni.h>'.

Marked as reviewed by jvernee (Reviewer).

I had a look at the implementation, and see how it works now. The JNI_OnLoad_XXX function is essentially being used as a marker to indicate that this library was statically linked into the VM binary, so we can create a `NativeLibrary` instance that is marked as 'builtin', which changes the way symbol lookups are handled.

I think the current solution is probably fine. I think alternatively we could keep track of a table with statically linked libraries to determine where/how symbols should be looked up for a particular library. Or, the symbol doesn't necessarily have to be JNI_OnLoad_XXX, but could be some other, non-JNI-specific, marker symbol.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24801#pullrequestreview-2799287975
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2835232241

From duke at openjdk.org  Mon Apr 28 13:34:29 2025
From: duke at openjdk.org (kuaiwei)
Date: Mon, 28 Apr 2025 13:34:29 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
Message-ID: <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>

> The patch fix error when creating devkit on wsl/msys2 .
> * Msys2 can be supported like cygwin
> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
> 
> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)

kuaiwei has updated the pull request incrementally with one additional commit since the last revision:

  Get SDK_INSTALL_DIR from enviroment variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24916/files
  - new: https://git.openjdk.org/jdk/pull/24916/files/b7cbe385..187e7016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24916&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24916&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24916/head:pull/24916

PR: https://git.openjdk.org/jdk/pull/24916

From erikj at openjdk.org  Mon Apr 28 13:35:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 13:35:52 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
Message-ID: <8Sz4UCfCW_5NTFSp3BuIe_V5F4Dh6aikcgdTOtwm18g=.c4d1fee3-c21a-4221-a075-dbebc7a5be82@github.com>

On Mon, 28 Apr 2025 09:15:28 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into pp2
>  - Fix class filtering
>  - Remove the workaround of setting AOTRecordTraining during assembly
>  - Address some of the review comments
>  - Merge branch 'master' into pp
>  - Add AOTCompileEagerly flag to control compilation after clinit
>  - Port 8355334: [leyden] Missing type profile info in archived training data
>  - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
>  - Use ENABLE_IF macro
>  - Missing part of the last commit
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/2447b981...7fb7ae62

Build changes look trivially good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24886#issuecomment-2835265306

From jvernee at openjdk.org  Mon Apr 28 13:43:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 13:43:52 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
Message-ID: <raFLpZsI7KOeHfIyNLxXfl4CwBdUkiOBMbYcaCdr4DI=.f0a4762b-771c-4791-ab21-69261fca963a@github.com>

On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>> 
>> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>> 
>> Also see #24705.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify FFM linker warmup

make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:

> 182:                 ADDRESS, ADDRESS, ADDRESS,
> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
> 184:         Linker.nativeLinker().downcallHandle(signature);

Why do we care specifically about this shape, but not about others?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063684813

From erikj at openjdk.org  Mon Apr 28 13:50:47 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 13:50:47 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
Message-ID: <wryu33n7Mm9pWK8pJHSUniWBviFCGx6zTlMPEBfVfpU=.e18ff7df-dea0-43ef-bfca-4350f9850111@github.com>

On Mon, 28 Apr 2025 13:34:29 GMT, kuaiwei <duke at openjdk.org> wrote:

>> The patch fix error when creating devkit on wsl/msys2 .
>> * Msys2 can be supported like cygwin
>> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
>> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
>> 
>> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get SDK_INSTALL_DIR from enviroment variable

Verified that it still works in Cygwin on my machine. Looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24916#pullrequestreview-2799371090

From liach at openjdk.org  Mon Apr 28 13:52:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 13:52:51 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <raFLpZsI7KOeHfIyNLxXfl4CwBdUkiOBMbYcaCdr4DI=.f0a4762b-771c-4791-ab21-69261fca963a@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
 <raFLpZsI7KOeHfIyNLxXfl4CwBdUkiOBMbYcaCdr4DI=.f0a4762b-771c-4791-ab21-69261fca963a@github.com>
Message-ID: <ba8ovVUmGVJTNY3i_5fUfV-4rDP9ezGlcVeeZru06sA=.0aba151c-3da2-4e85-b748-cdee5966a169@github.com>

On Mon, 28 Apr 2025 13:40:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify FFM linker warmup
>
> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:
> 
>> 182:                 ADDRESS, ADDRESS, ADDRESS,
>> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>> 184:         Linker.nativeLinker().downcallHandle(signature);
> 
> Why do we care specifically about this shape, but not about others?

That was from the past attempt of linking Class forName0. Tge exact shape doesn't really matter here as we are mainly saving on DMH.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063704198

From liach at openjdk.org  Mon Apr 28 14:11:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:11:57 GMT
Subject: RFR: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
References: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
Message-ID: <5KBmWMbdcGcEVuxWl3cEOncRU8n9qvps5jCox9SJQWE=.d00e6f1a-b764-44d4-b2ca-72b01ed99362@github.com>

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

Indeed, even if we want to construct a transformed handler, an instance method on `ClassFileTransform` is better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24908#issuecomment-2835381183

From liach at openjdk.org  Mon Apr 28 14:11:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:11:58 GMT
Subject: Withdrawn: 8355658: Allow transforms to run on elements generated by a
 builder
In-Reply-To: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
References: <t293SEG5sK5oxWYjZxcVyKCuDciQDnlHgS3wuTBpK8Q=.1645263a-2dab-4882-82fb-91df854ac42b@github.com>
Message-ID: <aDTWnxNZsYErCp_9wdLrWQexXoiuZSczm5Kq8a9I1Tk=.5efdf161-ec87-4591-a566-5ffcb7577628@github.com>

On Mon, 28 Apr 2025 01:43:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Transforms can run on a stream of class file elements. Currently, that stream can only be from a CompoundElement. We can allow a ClassFileBuilder to provide such a stream too; a recent request https://mail.openjdk.org/pipermail/classfile-api-dev/2025-April/000698.html asks for this as well.
> 
> With this patch, we can now emulate this ASM pattern easily:
> 
> 
> // ASM
> ClassVisitor cv = new DelegateClassVisitor(new ClassWriter(...));
> cv.visitXxx(); // write elements through the delegate
> 
> // ClassFile API
> cf.build(..., clb0 -> clb0.transforming((clb, cle) -> /*process */, clb -> {
>     // write elements through delegate
> }));
> 
> 
> Notably, this patch introduces a source incompatibility (but not binary) in order to allow users to call `transform(model, (xb, xe) -> {})` or `transforming((xb1, xe) -> {}, xb1 -> {})`. This has little impact if users don't use `ClassFileBuilder` as a type directly (which according to grep.app, there are only two sites on whole GitHub, both updated in this PR). A release note has been created for this incompatibility at https://bugs.openjdk.org/browse/JDK-8355665; please review too.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24908

From liach at openjdk.org  Mon Apr 28 14:26:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:26:46 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v2]
In-Reply-To: <ba8ovVUmGVJTNY3i_5fUfV-4rDP9ezGlcVeeZru06sA=.0aba151c-3da2-4e85-b748-cdee5966a169@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
 <Yghcx5_lYD0pTcH1phD5M-pkcymMN7H4ivBuHT4YhhM=.175e7784-cc11-4383-bfe3-d4931b444233@github.com>
 <raFLpZsI7KOeHfIyNLxXfl4CwBdUkiOBMbYcaCdr4DI=.f0a4762b-771c-4791-ab21-69261fca963a@github.com>
 <ba8ovVUmGVJTNY3i_5fUfV-4rDP9ezGlcVeeZru06sA=.0aba151c-3da2-4e85-b748-cdee5966a169@github.com>
Message-ID: <_bX7wPu7a39ujK5Wi-iS0IvVEfDHG438lCaNRXhT_R8=.fbad2ac1-97a1-417b-a080-f360f38dc66b@github.com>

On Mon, 28 Apr 2025 13:50:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 184:
>> 
>>> 182:                 ADDRESS, ADDRESS, ADDRESS,
>>> 183:                 JAVA_BOOLEAN, ADDRESS, ADDRESS);
>>> 184:         Linker.nativeLinker().downcallHandle(signature);
>> 
>> Why do we care specifically about this shape, but not about others?
>
> That was from the past attempt of linking Class forName0. Tge exact shape doesn't really matter here as we are mainly saving on DMH.

Can I just change this signature to `FunctionDescriptor.ofVoid()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24742#discussion_r2063776900

From mbaesken at openjdk.org  Mon Apr 28 14:27:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Apr 2025 14:27:50 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible [v2]
In-Reply-To: <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
Message-ID: <h2jVEd_6cGKqA01u6M4WTgWBt56-YaOp-ijY4nrrwLg=.712f561e-03b1-4474-a83a-f94e3714b9d6@github.com>

On Thu, 17 Apr 2025 15:42:09 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
>> Unfortunately there has to be some adoptions.
>> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
>> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
>> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comments

The warnings will be addressed in a follow up
https://bugs.openjdk.org/browse/JDK-8355594
8355594: Warnings occur when building with clang and enabling ubsan

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24667#issuecomment-2835433130

From liach at openjdk.org  Mon Apr 28 14:36:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Apr 2025 14:36:33 GMT
Subject: RFR: 8354996: Reduce dynamic code generation for a single downcall
 [v3]
In-Reply-To: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
References: <_xS9sPe6wGP1pJD6E-cy73SEY6SzWAGi66z8ujd3vRE=.cfd01eee-888f-4f15-afca-a0c09ac5b7b0@github.com>
Message-ID: <M7s6_JHhw3uJ8iaPL_eIy9p5BsXpuxx5Rm26pExRh60=.7209bb72-6272-449d-8e8f-3ddb319daf5f@github.com>

> Perf numbers for simple main:
> Linking of `Class::forName0` down from ~152 to ~83
> 
> For calling little color management system https://bugs.openjdk.org/browse/JDK-8313344:
> JNI: ~45
> baseline panama: ~164
> patch: ~103
> 
> Also see #24705.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Use more simple function descriptor
 - Simplify FFM linker warmup
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/ffm-lcms
 - Wip work trying to speed up FFM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24742/files
  - new: https://git.openjdk.org/jdk/pull/24742/files/dbf7799c..f762f72f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24742&range=01-02

  Stats: 46599 lines in 1266 files changed: 35620 ins; 7149 del; 3830 mod
  Patch: https://git.openjdk.org/jdk/pull/24742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24742/head:pull/24742

PR: https://git.openjdk.org/jdk/pull/24742

From clanger at openjdk.org  Mon Apr 28 14:38:52 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 28 Apr 2025 14:38:52 GMT
Subject: RFR: 8354686: [AIX] now ubsan is possible [v2]
In-Reply-To: <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
 <pztFIUrelWE9KsMaELOman1B1PeaBs7cb93dJ_r6YvM=.cbfc437a-f213-4b79-964b-bc2459f34da3@github.com>
Message-ID: <V0OfWA2x7wtlm_Xa0c8XLtKtWitbxJ78oQwtPEWPBWE=.c165ec64-1450-418e-8639-175584324ed2@github.com>

On Thu, 17 Apr 2025 15:42:09 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
>> Unfortunately there has to be some adoptions.
>> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
>> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
>> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding comments

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24667#pullrequestreview-2799542408

From jkern at openjdk.org  Mon Apr 28 14:41:59 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 28 Apr 2025 14:41:59 GMT
Subject: Integrated: 8354686: [AIX] now ubsan is possible
In-Reply-To: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
References: <UuIgHZOVEVJBtUGR2KsLWEW26vQfHjl7bqbuRclBrvA=.d0cbd2dc-7384-4d86-b481-4723a3b887df@github.com>
Message-ID: <Ibh1-UVZDFbbAZR49m84KIiFVHJRFB1-dSfOOFu1oe4=.fe2475e7-9a8d-4956-82e9-2bf9f65c5a76@github.com>

On Tue, 15 Apr 2025 18:40:57 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> With the introduction of the open XL 17.1.2.13 Compiler and the runtime 17.1.3 as minimum requirement ubsan is supported for AIX now.
> Unfortunately there has to be some adoptions.
> - Currently the test for vptr does not work and produces crashes when active, so we have to deactivate it. (If fixed by IBM there will be a follow up JBS)
> - ubsan introduces so much new symbols to every executable that we have to link with -bbictoc.
> - The llvm_symbolizer is not found out of the box, so we have to provide the full qualified llvm_symbolizer path in the __ubsan_default_options() function.

This pull request has now been integrated.

Changeset: b1e778d9
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b1e778d9d2ad13ee5f1ed629a8805008580f86c0
Stats:     24 lines in 2 files changed: 22 ins; 0 del; 2 mod

8354686: [AIX] now ubsan is possible

Reviewed-by: mbaesken, clanger

-------------

PR: https://git.openjdk.org/jdk/pull/24667

From mikael at openjdk.org  Mon Apr 28 15:17:06 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 28 Apr 2025 15:17:06 GMT
Subject: RFR: 8354902: Change to Visual Studio 17.13.2 for building on
 Windows at Oracle [v2]
In-Reply-To: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
References: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
Message-ID: <HO6RSaqrNkKWUipEBF7mHOwM2icHnjGG1Ih-64Z_P4g=.a14f2333-9bf5-4fd4-8f52-7ecd0e43e918@github.com>

> Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.
> 
> Testing: tier1-5

Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8354902-vs2022-17.13.2
 - 8354902: Change to Visual Studio 17.13.2 for building on Windows at Oracle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24707/files
  - new: https://git.openjdk.org/jdk/pull/24707/files/1b40d3b4..60052f4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24707&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24707&range=00-01

  Stats: 52440 lines in 1379 files changed: 40660 ins; 7599 del; 4181 mod
  Patch: https://git.openjdk.org/jdk/pull/24707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24707/head:pull/24707

PR: https://git.openjdk.org/jdk/pull/24707

From mbaesken at openjdk.org  Mon Apr 28 15:28:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Apr 2025 15:28:19 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan
Message-ID: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>

When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :


warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

-------------

Commit messages:
 - JDK-8355594

Changes: https://git.openjdk.org/jdk/pull/24924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355594
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24924/head:pull/24924

PR: https://git.openjdk.org/jdk/pull/24924

From jkern at openjdk.org  Mon Apr 28 16:01:57 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 28 Apr 2025 16:01:57 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan
In-Reply-To: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
Message-ID: <0wdBS8SFrfoOXGH1LgUgqH3B3HNGMev2KcnI7UgWVU8=.35212f10-c51c-4480-b68a-b4c13b131e9d@github.com>

On Mon, 28 Apr 2025 15:22:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
> 
> 
> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

Marked as reviewed by jkern (Committer).

make/autoconf/jdk-options.m4 line 526:

> 524:   if test "x$TOOLCHAIN_TYPE" = "xgcc"; then
> 525:     UBSAN_CFLAGS="$UBSAN_CFLAGS -Wno-stringop-truncation -Wno-format-overflow -Wno-stringop-overflow"
> 526:   fi

LGTM

-------------

PR Review: https://git.openjdk.org/jdk/pull/24924#pullrequestreview-2799855017
PR Review Comment: https://git.openjdk.org/jdk/pull/24924#discussion_r2063994800

From fthevenet at openjdk.org  Mon Apr 28 16:21:49 2025
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Mon, 28 Apr 2025 16:21:49 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
Message-ID: <x1XM9zgO_aL7Yh3VkBDQ0MtkfnIflCaZ4lkai-0UTg4=.9acf334f-3a67-4dd7-abe2-87da977dc162@github.com>

On Mon, 28 Apr 2025 13:34:29 GMT, kuaiwei <duke at openjdk.org> wrote:

>> The patch fix error when creating devkit on wsl/msys2 .
>> * Msys2 can be supported like cygwin
>> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
>> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
>> 
>> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get SDK_INSTALL_DIR from enviroment variable

**Please note that this is not a formal review, as I am not an OpenJDK reviewer.**

`createWindowsDevkit.sh` will fail to run when MSYS2 is started under any other environment[1] other than "MSYS" (i.e. `MINGW64`, `UCRT64`, `CLANG64`, etc...), because for all other env, `uname -r` will return `MINGW64_NT-10.0-26100` instead of `MSYS_NT-10.0-26100` which throws off the cygwin/msys2/wsl detection.

Is this deliberate, so as to ensure only the MSYS environment is supported for this feature, or an oversight?

Cheers!

[1] https://www.msys2.org/docs/environments/

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2835796879

From galder at redhat.com  Mon Apr 28 16:24:27 2025
From: galder at redhat.com (Galder Zamarreno)
Date: Mon, 28 Apr 2025 18:24:27 +0200
Subject: About compiling on macOS
In-Reply-To: <cad47d97-fefe-419e-bf96-d1dcb151a09b@gmail.com>
References: <64A5EE75-AE8B-4127-8567-EA8A73CAA1EC@daisuke2.com>
 <cad47d97-fefe-419e-bf96-d1dcb151a09b@gmail.com>
Message-ID: <CAAcPREtHpnJs6BRMGw8=zF9V6XiXVbx8Cm4wg_U3n1cETvyuWQ@mail.gmail.com>

XCode 16.2 worked fine for me. I also see the same warnings with XCode 16.3.

You can manually download XCode via
http://developer.apple.com/download/all/?q=Xcode. XCode 16.2 is still there
right now. Downloading it, unzipping it and putting elsewhere other than
/Applications might work if used alongside the `--with-xcode-path` flag
Jaikiran mentioned.

I've kept it simple and went with `--disable-warnings-as-errors`,
although I can easily swap my nix-shell to using the XCode 16.2 I still
have lying around in the Nix store.

Thanks
Galder


On Sun, Apr 27, 2025 at 9:35?AM Jaikiran Pai <jai.forums2013 at gmail.com>
wrote:

> A previous report too suggests that the JDK build fails (due to compiler
> warnings) when using 16.3 of Xcode on macos. Do you have access to a
> 15.4 version of Xcode instead? If so, then you can use
> "--with-xcode-path" during configure to point to that installation of
> Xcode and build the JDK (more details in the documentation here
> https://github.com/openjdk/jdk/blob/master/doc/building.md#apple-xcode).
> I believe that version should be fine.
>
> If you cannot use any other XCode other than 16.3, then you can build
> the JDK by using the "--disable-warnings-as-errors" configure option
> (more details here
>
> https://github.com/openjdk/jdk/blob/master/doc/building.md#problems-with-the-build-environment).
>
> Another user has reported previously that this option allowed them to
> successfully build with XCode 16.3.
>
> Long term, the warnings from that part of the code will have to be
> investigated in the JDK.
>
> -Jaikiran
>
> On 27/04/25 11:30 am, mitani at daisuke2.com wrote:
> > I have just compiled in the master branch. As a result, I am struggling
> with the following compilation errors.
> >
> > Configuration summary:
> > * Name:           macosx-aarch64-server-release
> > * Debug level:    release
> > * HS debug level: product
> > * JVM variants:   server
> > -n * JVM features:
> > -n server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check
> jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs
> zgc'
> >
> > * OpenJDK target: OS: macosx, CPU architecture: aarch64, address length:
> 64
> > * Version string: 25-internal-adhoc.mitani.jdk (25-internal)
> > * Source date:    1745733212 (2025-04-27T05:53:32Z)
> >
> > Tools summary:
> > * Boot JDK:       openjdk version "24.0.1" 2025-04-15 OpenJDK Runtime
> Environment Corretto-24.0.1.9.1 (build 24.0.1+9-FR) OpenJDK 64-Bit Server
> VM Corretto-24.0.1.9.1 (build 24.0.1+9-FR, mixed mode, sharing) (at
> /Library/Java/JavaVirtualMachines/amazon-corretto-24.jdk/Contents/Home)
> > * Toolchain:      clang (clang/LLVM from Xcode 16.3)
> > * Sysroot:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.4.sdk
> > * C Compiler:     Version 17.0.0 (at /usr/bin/clang)
> > * C++ Compiler:   Version 17.0.0 (at /usr/bin/clang++)
> >
> >
> >
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 127 | AudioDeviceID devices[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21:
> note: declared here
> > 126 | int count = size/sizeof(AudioDeviceID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 151 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21:
> note: declared here
> > 150 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16:
> note: declared here
> > 458 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9:
> note: declared here
> > 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9:
> note: declared here
> > 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 775 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18:
> note: declared here
> > 772 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 824 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18:
> note: declared here
> > 818 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> > 7 errors generated.
> > make[3]: ***
> [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o]
> Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > make[2]: *** [java.desktop-libs] Error 2
> > make[2]: *** Waiting for unfinished jobs....
> >
> > ERROR: Build failed for target 'default (exploded-image)' in
> configuration 'macosx-aarch64-server-release' (exit code 2)
> > Stopping javac server
> >
> > === Output from failing command(s) repeated here ===
> > * For target
> support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 127 | AudioDeviceID devices[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21:
> note: declared here
> > 126 | int count = size/sizeof(AudioDeviceID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 151 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21:
> note: declared here
> > 150 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > ... (rest of output omitted)
> >
> > * All command lines available in
> git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> > make: *** [default] Error 2
> > make
> > Building target 'default (exploded-image)' in configuration
> 'macosx-aarch64-server-release'
> > Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 152 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21:
> note: declared here
> > 151 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16:
> note: declared here
> > 459 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 528 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9:
> note: declared here
> > 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 530 | AudioControl* muteControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:530:32:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:525:9:
> note: declared here
> > 525 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 776 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:776:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:773:18:
> note: declared here
> > 773 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 825 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:825:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:819:18:
> note: declared here
> > 819 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> > 6 errors generated.
> > make[3]: ***
> [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o]
> Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > ld: warning: reducing alignment of section __DATA,__common from 0x8000
> to 0x4000 because it exceeds segment maximum alignment
> > make[2]: *** [java.desktop-libs] Error 2
> >
> > ERROR: Build failed for target 'default (exploded-image)' in
> configuration 'macosx-aarch64-server-release' (exit code 2)
> >
> > === Output from failing command(s) repeated here ===
> > * For target
> support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 152 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:152:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:21:
> note: declared here
> > 151 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 484 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:484:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:459:16:
> note: declared here
> > 459 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:528:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > ... (rest of output omitted)
> >
> > * All command lines available in
> git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> > make: *** [default] Error 2
> > make
> > Building target 'default (exploded-image)' in configuration
> 'macosx-aarch64-server-release'
> > Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87:
> error: use of undeclared identifier 'controlIDs'
> > 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID),
> &controlIDs, 1);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74:
> error: use of undeclared identifier 'controlIDs'
> > 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16:
> note: declared here
> > 460 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9:
> note: declared here
> > 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 531 | AudioControl* muteControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:531:32:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:526:9:
> note: declared here
> > 526 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 777 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:777:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:774:18:
> note: declared here
> > 774 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 826 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:826:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:820:18:
> note: declared here
> > 820 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> > 7 errors generated.
> > make[3]: ***
> [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o]
> Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > make[2]: *** [java.desktop-libs] Error 2
> >
> > ERROR: Build failed for target 'default (exploded-image)' in
> configuration 'macosx-aarch64-server-release' (exit code 2)
> >
> > === Output from failing command(s) repeated here ===
> > * For target
> support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:154:87:
> error: use of undeclared identifier 'controlIDs'
> > 154 | kAudioObjectPropertyOwnedObjects, count * sizeof(AudioObjectID),
> &controlIDs, 1);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:160:74:
> error: use of undeclared identifier 'controlIDs'
> > 160 | if (ctrl->audioControls[i]->controlID == controlIDs[j]) {
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 485 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:485:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:460:16:
> note: declared here
> > 460 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 529 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master
> channel
> > ... (rest of output omitted)
> >
> > * All command lines available in
> git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> > make: *** [default] Error 2
> > git reset --hard
> > HEAD is now at 898d4798003 8355077: Compiler error at splashscreen_gif.c
> due to unterminated string initialization
> > make
> > Building target 'default (exploded-image)' in configuration
> 'macosx-aarch64-server-release'
> > Creating support/modules_libs/java.desktop/libjsound.dylib from 1 file(s)
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 127 | AudioDeviceID devices[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21:
> note: declared here
> > 126 | int count = size/sizeof(AudioDeviceID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 151 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21:
> note: declared here
> > 150 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 483 | AudioObjectID controlIDs[mixer->deviceControlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> note: read of non-constexpr variable 'mixer' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:458:16:
> note: declared here
> > 458 | PortMixer *mixer = (PortMixer *)id;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 527 | AudioControl* volumeControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:527:34:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9:
> note: declared here
> > 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 529 | AudioControl* muteControls[totalChannels+1]; // 0 - for master
> channel
> > | ^~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:529:32:
> note: read of non-const variable 'totalChannels' is not allowed in a
> constant expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:524:9:
> note: declared here
> > 524 | int totalChannels = GetChannelCount(mixer->deviceID, port->scope
> == kAudioDevicePropertyScopeOutput ? 1 : 0);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 775 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:775:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:772:18:
> note: declared here
> > 772 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 824 | Float32 subVolumes[control->controlCount];
> > | ^~~~~~~~~~~~~~~~~~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:824:24:
> note: read of non-constexpr variable 'control' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:818:18:
> note: declared here
> > 818 | PortControl *control = (PortControl *)controlIDV;
> > | ^
> > 7 errors generated.
> > make[3]: ***
> [git/jdk/build/macosx-aarch64-server-release/support/native/java.desktop/libjsound/PLATFORM_API_MacOSX_Ports.o]
> Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > make[2]: *** [java.desktop-libs] Error 2
> >
> > ERROR: Build failed for target 'default (exploded-image)' in
> configuration 'macosx-aarch64-server-release' (exit code 2)
> >
> > === Output from failing command(s) repeated here ===
> > * For target
> support_native_java.desktop_libjsound_PLATFORM_API_MacOSX_Ports.o:
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 127 | AudioDeviceID devices[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:126:21:
> note: declared here
> > 126 | int count = size/sizeof(AudioDeviceID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > 151 | AudioObjectID controlIDs[count];
> > | ^~~~~
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:151:42:
> note: read of non-const variable 'count' is not allowed in a constant
> expression
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:150:21:
> note: declared here
> > 150 | int count = size / sizeof(AudioObjectID);
> > | ^
> >
> git/jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:483:38:
> error: variable length arrays in C++ are a Clang extension
> [-Werror,-Wvla-cxx-extension]
> > ... (rest of output omitted)
> >
> > * All command lines available in
> git/jdk/build/macosx-aarch64-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]: *** [main] Error 2
> > make: *** [default] Error 2
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250428/e4fb32c7/attachment-0001.htm>

From erikj at openjdk.org  Mon Apr 28 16:36:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 16:36:45 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan
In-Reply-To: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
Message-ID: <2LBDDdZneQ7e76Sh5q6k4YvC1BQg_eEyngrhjmZO5zs=.de3bc91e-258f-40fe-aac6-25d132cbeb15@github.com>

On Mon, 28 Apr 2025 15:22:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
> 
> 
> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24924#pullrequestreview-2799963191

From mikael at openjdk.org  Mon Apr 28 17:16:52 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 28 Apr 2025 17:16:52 GMT
Subject: Integrated: 8354902: Change to Visual Studio 17.13.2 for building on
 Windows at Oracle
In-Reply-To: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
References: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
Message-ID: <VHEQ07HSOXBMeAE_riLWs_YDrvAAL6gFxZv7H8dzypI=.dd20179d-1b4a-4f64-9714-90cd1ba0a098@github.com>

On Thu, 17 Apr 2025 01:17:50 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: a090aa3f
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a090aa3ff8b79b553061e8d61bc42eb3d915c955
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8354902: Change to Visual Studio 17.13.2 for building on Windows at Oracle

Reviewed-by: erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/24707

From mikael at openjdk.org  Mon Apr 28 17:16:52 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 28 Apr 2025 17:16:52 GMT
Subject: RFR: 8354902: Change to Visual Studio 17.13.2 for building on
 Windows at Oracle [v2]
In-Reply-To: <HO6RSaqrNkKWUipEBF7mHOwM2icHnjGG1Ih-64Z_P4g=.a14f2333-9bf5-4fd4-8f52-7ecd0e43e918@github.com>
References: <XIqCCaLOuFwFyI5CAJmCCexK5R0wT7SPN_gK46O9Hrs=.ca23507f-1b19-4707-a9a1-a5af48f488cf@github.com>
 <HO6RSaqrNkKWUipEBF7mHOwM2icHnjGG1Ih-64Z_P4g=.a14f2333-9bf5-4fd4-8f52-7ecd0e43e918@github.com>
Message-ID: <2No6xB_mkBNtJx7vHpLAZFSFFAMfy4LMtX-I3pq85e0=.29266144-3bb1-4666-9971-1e3596737aed@github.com>

On Mon, 28 Apr 2025 15:17:06 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Oracle is updating the version of Visual Studio for building the JDK on Windows to Visual Studio 2022 17.13.2.
>> 
>> Testing: tier1-5
>
> Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8354902-vs2022-17.13.2
>  - 8354902: Change to Visual Studio 17.13.2 for building on Windows at Oracle

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24707#issuecomment-2835933596

From kvn at openjdk.org  Mon Apr 28 17:37:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 28 Apr 2025 17:37:54 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
Message-ID: <sxJezTFWs3ipwJWrWvlasO4UtDyFsekLKbbVXn9wiSc=.ac69946c-9563-4f07-bcd0-ea701b5213f5@github.com>

On Mon, 28 Apr 2025 09:15:28 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into pp2
>  - Fix class filtering
>  - Remove the workaround of setting AOTRecordTraining during assembly
>  - Address some of the review comments
>  - Merge branch 'master' into pp
>  - Add AOTCompileEagerly flag to control compilation after clinit
>  - Port 8355334: [leyden] Missing type profile info in archived training data
>  - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
>  - Use ENABLE_IF macro
>  - Missing part of the last commit
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/2447b981...7fb7ae62

Looks better.
There are still places where UL is used specifically for TD processing. Consider using `(aot, training)` there instead of `(cds)`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2800131686

From iveresov at openjdk.org  Mon Apr 28 18:20:48 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 28 Apr 2025 18:20:48 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <sxJezTFWs3ipwJWrWvlasO4UtDyFsekLKbbVXn9wiSc=.ac69946c-9563-4f07-bcd0-ea701b5213f5@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
 <sxJezTFWs3ipwJWrWvlasO4UtDyFsekLKbbVXn9wiSc=.ac69946c-9563-4f07-bcd0-ea701b5213f5@github.com>
Message-ID: <dI_v8x5GZDL0BdO23r61MruBTxqUJ2NzahlyxW-OPEY=.5c06f190-e23e-4cd7-8df5-308681aa9557@github.com>

On Mon, 28 Apr 2025 17:35:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks better. There are still places where UL is used specifically for TD processing. Consider using `(aot, training)` there instead of `(cds)`.

Right. I haven't addressed these review comments yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24886#issuecomment-2836100964

From jiangli at openjdk.org  Mon Apr 28 18:27:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:27:02 GMT
Subject: RFR: 8355669: Add static-jdk-bundles make target
Message-ID: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>

Please review this PR that adds the static-jdk-bundles make target. The static-jdk-bundles is needed by JDK-8355452 (https://bugs.openjdk.org/browse/JDK-8355452) for adding tier1 tests on linux-x64 static-jdk in GHA.

-------------

Commit messages:
 - Add static-jdk-bundles make target.

Changes: https://git.openjdk.org/jdk/pull/24934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355669
  Stats: 29 lines in 3 files changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24934/head:pull/24934

PR: https://git.openjdk.org/jdk/pull/24934

From jiangli at openjdk.org  Mon Apr 28 18:57:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:55 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <QsdrYOJfCnK8QFDVAJr79nxxV04obwX92GFyNTtj1rE=.9ade70cb-eadc-4eeb-ac8b-ae7504408689@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
 <QsdrYOJfCnK8QFDVAJr79nxxV04obwX92GFyNTtj1rE=.9ade70cb-eadc-4eeb-ac8b-ae7504408689@github.com>
Message-ID: <iJ5VPu6zs6oFsub5GeykkEdx4o4CGDtJn0NBT7kfjEw=.b7edcb39-48c5-48b2-a272-37d066184f5f@github.com>

On Mon, 28 Apr 2025 13:04:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.
> 
> I remember this wasn't quite as elegant on Windows, but I suppose there is already some solution in place to look up symbols that are statically linked into the same executable?

With the current effort for enhancing/completing static JDK support, the system is able to detect if it's running on static using checks like `is_vm_statically_linked/JVM_IsStaticallyLinked/JLI_IsStaticallyLinked`. For example, `os::native_java_library` (https://github.com/openjdk/jdk/blob/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa/src/hotspot/share/runtime/os.cpp#L516) and `load_zip_library` retrieve the `os::get_default_process_handle` without doing `dlopen` (e.g. on Linux) to load the native libraries. For longer term, we can make the solution more coherent/general for handling the various cases in the system.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836196239

From jiangli at openjdk.org  Mon Apr 28 18:57:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:57 GMT
Subject: Integrated: 8355080:
 java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK
In-Reply-To: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
Message-ID: <kDIZoZP96vG_yFhTSo9SOKabWylpWDSWuCVsDzNL1WY=.787eab94-4854-4dbf-881f-05c37466dfaf@github.com>

On Tue, 22 Apr 2025 21:08:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
> 
> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
> 
> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.

This pull request has now been integrated.

Changeset: acd93df6
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd93df612525777656701821338caf9c81e5a6a
Stats:     37 lines in 5 files changed: 20 ins; 7 del; 10 mod

8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/24801

From jiangli at openjdk.org  Mon Apr 28 18:57:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 18:57:56 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
Message-ID: <i4xOC5FUyi9uo93c9DTj1wDL5ElH5a0GvzLegUZK-Vk=.55bb5aff-33b3-4f05-9722-1c5010c3db8c@github.com>

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

@mcimadamore @JornVernee Thanks for the in-depth thoughts and reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836201103

From ihse at openjdk.org  Mon Apr 28 19:26:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:26:48 GMT
Subject: RFR: 8355669: Add static-jdk-bundles make target
In-Reply-To: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>
References: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>
Message-ID: <ombjAsDPaajEXFmLoQx6uZ1rQnlpctxZx0GPnfpYGj0=.412e1409-a526-409f-ad29-ad153a83911a@github.com>

On Mon, 28 Apr 2025 18:22:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds the static-jdk-bundles make target. The static-jdk-bundles is needed by JDK-8355452 (https://bugs.openjdk.org/browse/JDK-8355452) for adding tier1 tests on linux-x64 static-jdk in GHA.

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24934#pullrequestreview-2800468018

From ihse at openjdk.org  Mon Apr 28 19:28:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:28:45 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan
In-Reply-To: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
Message-ID: <yd7SsUYYHd2IHo3Qo_Yu84R5xvEyeN5Z5EUjzlqSCeQ=.c54ca964-2942-47ea-9efe-81c286eb3f38@github.com>

On Mon, 28 Apr 2025 15:22:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
> 
> 
> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

Marked as reviewed by ihse (Reviewer).

make/autoconf/jdk-options.m4 line 525:

> 523:   UBSAN_CFLAGS="$UBSAN_CHECKS -Wno-array-bounds -fno-omit-frame-pointer -DUNDEFINED_BEHAVIOR_SANITIZER"
> 524:   if test "x$TOOLCHAIN_TYPE" = "xgcc"; then
> 525:     UBSAN_CFLAGS="$UBSAN_CFLAGS -Wno-stringop-truncation -Wno-format-overflow -Wno-stringop-overflow"

Just for the sake of my sanity, can you reorder the `-Wno-*` options in alphabetical order?

-------------

PR Review: https://git.openjdk.org/jdk/pull/24924#pullrequestreview-2800472851
PR Review Comment: https://git.openjdk.org/jdk/pull/24924#discussion_r2064376949

From jiangli at openjdk.org  Mon Apr 28 19:31:45 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 19:31:45 GMT
Subject: RFR: 8355669: Add static-jdk-bundles make target
In-Reply-To: <ombjAsDPaajEXFmLoQx6uZ1rQnlpctxZx0GPnfpYGj0=.412e1409-a526-409f-ad29-ad153a83911a@github.com>
References: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>
 <ombjAsDPaajEXFmLoQx6uZ1rQnlpctxZx0GPnfpYGj0=.412e1409-a526-409f-ad29-ad153a83911a@github.com>
Message-ID: <X7PCSgEsJYETOvwvZAJW2XIfvFoT3QHPqBISxx9Qbw0=.c8307dcb-1157-4d0d-bcb4-069ae4bf564b@github.com>

On Mon, 28 Apr 2025 19:24:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that adds the static-jdk-bundles make target. The static-jdk-bundles is needed by JDK-8355452 (https://bugs.openjdk.org/browse/JDK-8355452) for adding tier1 tests on linux-x64 static-jdk in GHA.
>
> Marked as reviewed by ihse (Reviewer).

@magicus Thank you for the quick review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24934#issuecomment-2836294322

From ihse at openjdk.org  Mon Apr 28 19:32:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:32:45 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
Message-ID: <SAXWPpkli8NPKaU0UfoxnUdfHzHlUIvg2dZFwT6QV6k=.c532700b-ad52-4172-b7c5-d80ed5c4fb7a@github.com>

On Mon, 28 Apr 2025 13:34:29 GMT, kuaiwei <duke at openjdk.org> wrote:

>> The patch fix error when creating devkit on wsl/msys2 .
>> * Msys2 can be supported like cygwin
>> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
>> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
>> 
>> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get SDK_INSTALL_DIR from enviroment variable

make/devkit/createWindowsDevkit.sh line 69:

> 67: elif test "x$IS_MSYS" != "x"; then
> 68:     BUILD_ENV="cygwin"
> 69:     CMD_EXE="cmd.exe //c"

The `//c` is a hacky solution. 

I think it would be better if you exported `MSYS2_ARG_CONV_EXCL="*"` -- you can do that without testing for windows environment since it does not really matter on anything but msys.

Then you can skip `CMD_EXE` and keep the single-slash variant for all environments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24916#discussion_r2064383756

From ihse at openjdk.org  Mon Apr 28 19:35:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:35:55 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
Message-ID: <DYoNAEWVuPEtNv2b72kMU6Vxj7ItfiCGIdyFrvTXIYs=.3c0f99da-abeb-47f1-be79-8e8b3a3f5b4a@github.com>

On Mon, 28 Apr 2025 09:15:28 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into pp2
>  - Fix class filtering
>  - Remove the workaround of setting AOTRecordTraining during assembly
>  - Address some of the review comments
>  - Merge branch 'master' into pp
>  - Add AOTCompileEagerly flag to control compilation after clinit
>  - Port 8355334: [leyden] Missing type profile info in archived training data
>  - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
>  - Use ENABLE_IF macro
>  - Missing part of the last commit
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/2447b981...7fb7ae62

Build changes are trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2800489948

From ihse at openjdk.org  Mon Apr 28 19:38:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:38:44 GMT
Subject: RFR: 8355570: [s390x] Update -march to z13 generation
In-Reply-To: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
References: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
Message-ID: <MzQei2wdmgB1n0dlofT5m5uVnyZmijXaraYE1X8UAxk=.03e72917-918f-4ce7-a840-a1992cb840d6@github.com>

On Fri, 25 Apr 2025 06:24:31 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> updated march level from z10 to z13.
> 
> Testing: tier1 (fastdebug-vm)

This is a failure when building the gtest framework. 

Could this different arch flag be sensitive to different gcc versions? When you say you tested locally, what gcc version did you use?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2836309762

From jiangli at openjdk.org  Mon Apr 28 19:46:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 28 Apr 2025 19:46:52 GMT
Subject: Integrated: 8355669: Add static-jdk-bundles make target
In-Reply-To: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>
References: <K60P1-E36QNGg0n6c1kFcOhXiDUabIIlxx_qPdYHwy0=.ca1788c9-43db-41a3-b5dd-41cf3897ab51@github.com>
Message-ID: <5h05YWDara_HUNG_zlvHlLULTj2Lyo5at6IzYcbdK_A=.a5871b7b-6b3b-4c36-94ee-b52366fe5de2@github.com>

On Mon, 28 Apr 2025 18:22:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds the static-jdk-bundles make target. The static-jdk-bundles is needed by JDK-8355452 (https://bugs.openjdk.org/browse/JDK-8355452) for adding tier1 tests on linux-x64 static-jdk in GHA.

This pull request has now been integrated.

Changeset: 62d165d0
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62d165d0e4e5ab1bcef35d5031554a354052c6d5
Stats:     29 lines in 3 files changed: 28 ins; 0 del; 1 mod

8355669: Add static-jdk-bundles make target

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/24934

From ihse at openjdk.org  Mon Apr 28 19:50:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 19:50:52 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
Message-ID: <wNHPQFJJeCMGYmhZz-qjF4t-WPg9lIbFtSCXfwhg4rs=.f2527093-97c6-4a9d-be0e-ddaaf367767e@github.com>

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

@mcimadamore 

> Having to upgrade to JNI is a bit sad 

I'm not quite sure what you mean that "upgrades" the library to a "JNI library"? Nor why this is sad?

What we do is that we add a marker to identify the library as a built-in library. The name of the marker contains the letters `JNI`, but that is the only JNI thing about it. As Jiangli says, we have added this marker for all other internal JDK libraries. I agree that the name could have been better, but it seems like a minor detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836346969

From magnus.ihse.bursie at oracle.com  Mon Apr 28 20:05:39 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 22:05:39 +0200
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <2f767360-8c81-48f0-8374-344e47865748@oracle.com>

I thought I recognized this issue, and started searching the mail 
archive. Seems the same question was asked last year by ... you. :-)

https://mail.openjdk.org/pipermail/build-dev/2024-August/046011.html

I guess nobody still has a simple answer to give you. I don't understand 
how the msan internal functions are supposed to work, if there is no 
library to link to. Are they added by the compiler?

Maybe you can try patching out -fvisibility=hidden from the compile 
command line to see if that makes any difference.

/Magnus

On 2025-04-25 16:28, Baesken, Matthias wrote:
>
> Hi,? Memory sanitizer
>
> https://clang.llvm.org/docs/MemorySanitizer.html
>
> is supported with the clang toolchain? (e.g. on Linux) ;? 
> ?MemorySanitizer is a detector of uninitialized memory use?? .
>
> For small examples it is rather easy to use,?? you just compile and 
> link?? with -fsanitize=memory ?????(and for better results maybe 
> additionally? -fno-omit-frame-pointer )?? .
>
> So I gave it a try with OpenJDK too and added? ?-fsanitize=memory 
> ?????to the? C/CXX and LD flags 
> ?(--with-extra-cflags=-fsanitize=memory 
> --with-extra-cxxflags=-fsanitize=memory 
> --with-extra-ldflags=-fsanitize=memory ).
>
> As far as compiling single? compilation units this seems to be okay .
>
> But when it comes to executing the new generated binaries in the build 
> process? we unfortunately get? lookup errors / undefined symbols? ?:
>
> /builddir/jdk/bin/javac: symbol lookup error: 
> ?/builddir/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls
>
> Is there something special in our OpenJDK build that causes trouble here ?
>
> Here I found an somewhat similar looking issue :
>
> https://groups.google.com/g/memory-sanitizer/c/xV3OZZCiL9A
>
> where re-exporting symbols is mentioned - is this maybe something that 
> hits us in OpenJDK too ?
>
> For address sanitizer, we set -shared-libasan in the OpenJDK :
>
> https://github.com/openjdk/jdk/blob/5c067232bf21aaca2b7addd2a862e15a8696ffb8/make/autoconf/jdk-options.m4#L449
>
> ASAN_LDFLAGS="$ASAN_LDFLAGS -shared-libasan"
>
> But I could not find something similar for msan .
>
> (btw. I use clang 15.0.7 on SUSE Linux x86_64 in case this matters)
>
> Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250428/76ad6d82/attachment-0001.htm>

From ihse at openjdk.org  Mon Apr 28 20:10:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:10:49 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
Message-ID: <x0VkxY9ifIckw1henfJgKwqh7sY6RdF92c7lDg2lxzI=.974fef8b-ebc1-434a-9a01-cfc414127455@github.com>

On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata <duke at openjdk.org> wrote:

>> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI.
>> 
>> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency.
>> 
>> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file.
>> Note: In my environment, it worked correctly even without these options.
>> 
>> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in:
>> 
>> - `environment.html`: `windows/system/os` section
>> - `process.html`: `[Process ID]/windows/native/info` section
>> 
>> **Testing:**
>> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes.
>
> Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run jcheck

make/autoconf/build-performance.m4 line 78:

> 76:   elif test "x$OPENJDK_BUILD_OS" = xwindows; then
> 77:     # Windows, but without cygwin
> 78:     MEMORY_SIZE=`powershell -Command \

We should actually lookup the path of powershell and refer to it as `$POWERSHELL` instead of hard-coding it like this. But I see that the entire BPERF_CHECK_MEMORY_SIZE calls unverified tools on all platforms, and this is not a regression, so I'll let this slip for now.

Are we sure powershell is always installed on Windows?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24791#discussion_r2064464221

From ihse at openjdk.org  Mon Apr 28 20:12:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:12:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v9]
In-Reply-To: <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>
Message-ID: <MP-yrnmJU5zCfu-McanoUeKsOvCz9nDT6iWwHUAu4hQ=.a44648cc-a05a-450a-9d89-cabeecf0bdcb@github.com>

On Sun, 27 Apr 2025 22:22:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into JDK-8350209
>  - Downgraded UL as asked. Added synchronization to C strings caching.
>  - Fix message
>  - Generate far jumps for AOT code on AArch64
>  - remove _enabled suffix
>  - Add sanity test for AOTAdapterCaching flag
>  - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
>  - Removed unused AOTCodeSection class
>  - 8350209: Preserve adapters in AOT cache

Build change is trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2800601222

From ihse at openjdk.org  Mon Apr 28 20:15:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:15:49 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <TbYEEt-uzoycdBvMggRFL-n4vEyns92se7ZPxzpSDgk=.615b827e-3dab-4805-96fa-0805cba5277a@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

This is much better; I did not realize this was possible. I agree that sprinkling dot files all over the source code is a bad thing.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24714#pullrequestreview-2800608010

From ihse at openjdk.org  Mon Apr 28 20:31:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:31:45 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
Message-ID: <IT9avsq3XWoPLmoUsIwkI7fO_ZAJ6QHYN2dNyFyaiwM=.e5c55671-2f11-4032-870c-d9bd64255944@github.com>

On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.

My understanding here is that we unpack four different jars: jmh-core, jmh-generator-annprocess, jopt-simple and commons-math3. The removal of *.xml is done on the single directory where all of the jars were unpacked into, so the intended target could be xml files in any of these, not just jmh-core .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2836472997

From ihse at openjdk.org  Mon Apr 28 20:35:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Apr 2025 20:35:45 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
Message-ID: <tZmRl-xQKEOJNNGwz-FJPMhrXfjhgGPJwI9qsTaA5e4=.e9dfc1e6-66f7-4c35-a9e6-db85fb62eef4@github.com>

On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler.

With that said, it is very much unclear why this line is here at all. The removal of xml files is from the original integration of microbenchmarks, JDK-8061281, and the reason behind it is lost in time.

But if this works, and does not break any existing microbenchmark tests, I don't see any problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2836494237

From jvernee at openjdk.org  Mon Apr 28 22:43:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 28 Apr 2025 22:43:50 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <OimDHKVl14T5kvOWIXAMcDdq7aCGTaRAupzq6RlJNrI=.4fb1239e-ad42-49cf-91a2-64fc9d05fc33@github.com>
Message-ID: <q4STOb10KocfiIYf5Y_SwYsIF0R5oHf1IzkAysVhN5w=.6b5f42d9-f95b-4c51-b6fb-f11b941f37fa@github.com>

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

> @mcimadamore
> 
> > Having to upgrade to JNI is a bit sad
> 
> I'm not quite sure what you mean that "upgrades" the library to a "JNI library"? Nor why this is sad?

JNI libraries are more restrictive than non-JNI libraries, as JNI libraries can only be loaded by a single class loader. The lifetime of the class loader is re-used as the lifetime of the library, and tells us when OnLoad and OnUnload should be called. This is in particular not needed in this case, and gets us away from the loaded-by-single-class-loader restricted, but as Maurizio says, making this library a JNI library is probably okay, since this class should always be loaded by the boot loader.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836921541

From erikj at openjdk.org  Mon Apr 28 23:05:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 23:05:45 GMT
Subject: RFR: 8355249: Remove the use of WMIC from the entire source code
 [v2]
In-Reply-To: <x0VkxY9ifIckw1henfJgKwqh7sY6RdF92c7lDg2lxzI=.974fef8b-ebc1-434a-9a01-cfc414127455@github.com>
References: <blL6FOj7XD1T3u_ODIwYPIPDXEowzSR0w5j92nC9gCo=.8a2428d9-1795-4dd0-91fd-8b604c7cc100@github.com>
 <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com>
 <x0VkxY9ifIckw1henfJgKwqh7sY6RdF92c7lDg2lxzI=.974fef8b-ebc1-434a-9a01-cfc414127455@github.com>
Message-ID: <_UAezO_9udU58185ILRhZPrnVaRCM0H4amsoq4Txxiw=.66f164e7-2ffe-4cca-92bd-848ecffb2ff7@github.com>

On Mon, 28 Apr 2025 20:08:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Are we sure powershell is always installed on Windows?

I verified by running tests on all the Windows versions we use internally and looked at the calculated concurrency in RunTest.gmk. If we didn't get a number for memory I believe concurrency would end up as `1`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24791#discussion_r2064977925

From erikj at openjdk.org  Mon Apr 28 23:12:44 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Apr 2025 23:12:44 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <tZmRl-xQKEOJNNGwz-FJPMhrXfjhgGPJwI9qsTaA5e4=.e9dfc1e6-66f7-4c35-a9e6-db85fb62eef4@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
 <tZmRl-xQKEOJNNGwz-FJPMhrXfjhgGPJwI9qsTaA5e4=.e9dfc1e6-66f7-4c35-a9e6-db85fb62eef4@github.com>
Message-ID: <Ett3UTOEuxrfiOFXWoJz8CeSACuYNR-WobLGw3iuyoU=.7b3a9042-15d2-467a-bcb2-b09c0e1e344b@github.com>

On Mon, 28 Apr 2025 20:33:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With that said, it is very much unclear why this line is here at all. The removal of xml files is from the original integration of microbenchmarks, JDK-8061281, and the reason behind it is lost in time.

As I wrote above:

>The rm command seems to be aimed at checkstyle.xml and findbugs.xml, both of which I would assume to be irrelevant, but should also be benign, but I can't help but wonder why those files are included in the JMH distribution.

That was based on inspecting all 4 jars. I highly doubt there was anything more sinister or dangerous hidden in any of the jar files historically. These seemingly irrelevant files seem enough to have warranted this file removal to me at least. I do think it's a bug that JMH is bundling its checkstyle and findbugs configurations in its distribution jar, so perhaps we can suggest to a JMH maintainer to stop doing that. :)

Regardless, the files should be benign so removing the `rm` line seems fine to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2836976702

From duke at openjdk.org  Tue Apr 29 02:49:52 2025
From: duke at openjdk.org (kuaiwei)
Date: Tue, 29 Apr 2025 02:49:52 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <x1XM9zgO_aL7Yh3VkBDQ0MtkfnIflCaZ4lkai-0UTg4=.9acf334f-3a67-4dd7-abe2-87da977dc162@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
 <x1XM9zgO_aL7Yh3VkBDQ0MtkfnIflCaZ4lkai-0UTg4=.9acf334f-3a67-4dd7-abe2-87da977dc162@github.com>
Message-ID: <X565qQzCh5J26QclY-q-rVCCkX7ayZCEpA4nGDh0aKM=.2d68dd01-a47e-447d-959b-e9fcbcba160c@github.com>

On Mon, 28 Apr 2025 16:19:09 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> **Please note that this is not a formal review, as I am not an OpenJDK reviewer.**
> 
> `createWindowsDevkit.sh` will fail to run when MSYS2 is started under any other environment[1] other than "MSYS" (i.e. `MINGW64`, `UCRT64`, `CLANG64`, etc...), because for all other env, `uname -s` will return `MINGW64_NT-10.0-26100` instead of `MSYS_NT-10.0-26100` which throws off the cygwin/msys2/wsl detection.
> 
> Is this deliberate, so as to ensure only the MSYS environment is supported for this feature, or an oversight?
> 
> Cheers!
> 
> [1] https://www.msys2.org/docs/environments/

Thanks for testing it. I checked other environments and think it's more reliable to check output of `uname -o` for msys. It always output 'Msys' in my testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2837295634

From duke at openjdk.org  Tue Apr 29 03:38:33 2025
From: duke at openjdk.org (kuaiwei)
Date: Tue, 29 Apr 2025 03:38:33 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v3]
In-Reply-To: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
Message-ID: <qg6te_c7wTE8JUIVZrbTDhbigCq-EPTaBpOfH7_9KoM=.2b257b0b-c41f-4a19-b034-279e9975556a@github.com>

> The patch fix error when creating devkit on wsl/msys2 .
> * Msys2 can be supported like cygwin
> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
> 
> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)

kuaiwei has updated the pull request incrementally with one additional commit since the last revision:

  Support more msys2 environments and use MSYS2_ARG_CONV_EXCL for cmd.exe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24916/files
  - new: https://git.openjdk.org/jdk/pull/24916/files/187e7016..a81a294e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24916&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24916&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24916/head:pull/24916

PR: https://git.openjdk.org/jdk/pull/24916

From duke at openjdk.org  Tue Apr 29 03:38:34 2025
From: duke at openjdk.org (kuaiwei)
Date: Tue, 29 Apr 2025 03:38:34 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <SAXWPpkli8NPKaU0UfoxnUdfHzHlUIvg2dZFwT6QV6k=.c532700b-ad52-4172-b7c5-d80ed5c4fb7a@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
 <SAXWPpkli8NPKaU0UfoxnUdfHzHlUIvg2dZFwT6QV6k=.c532700b-ad52-4172-b7c5-d80ed5c4fb7a@github.com>
Message-ID: <F5CAGlIkxY8OtRFv2xgw4tBcFCcql2oOsoR_qxvnc7M=.13509a9e-6326-482d-a2d7-841c97402d3e@github.com>

On Mon, 28 Apr 2025 19:30:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get SDK_INSTALL_DIR from enviroment variable
>
> make/devkit/createWindowsDevkit.sh line 69:
> 
>> 67: elif test "x$IS_MSYS" != "x"; then
>> 68:     BUILD_ENV="cygwin"
>> 69:     CMD_EXE="cmd.exe //c"
> 
> The `//c` is a hacky solution. 
> 
> I think it would be better if you exported `MSYS2_ARG_CONV_EXCL="*"` -- you can do that without testing for windows environment since it does not really matter on anything but msys.
> 
> Then you can skip `CMD_EXE` and keep the single-slash variant for all environments.

Thanks for your comments. I added `MSYS2_ARG_CONV_EXCL="*"` in script and tested with msys.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24916#discussion_r2065365968

From ihse at openjdk.org  Tue Apr 29 05:53:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Apr 2025 05:53:48 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v3]
In-Reply-To: <qg6te_c7wTE8JUIVZrbTDhbigCq-EPTaBpOfH7_9KoM=.2b257b0b-c41f-4a19-b034-279e9975556a@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <qg6te_c7wTE8JUIVZrbTDhbigCq-EPTaBpOfH7_9KoM=.2b257b0b-c41f-4a19-b034-279e9975556a@github.com>
Message-ID: <s5x6yYjkd4-z7J2UPyqXioO-oVrzHFEP5jJYRlH8K9E=.f7fc3f1a-56a3-42fd-bc47-71e39043e297@github.com>

On Tue, 29 Apr 2025 03:38:33 GMT, kuaiwei <duke at openjdk.org> wrote:

>> The patch fix error when creating devkit on wsl/msys2 .
>> * Msys2 can be supported like cygwin
>> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
>> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
>> 
>> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support more msys2 environments and use MSYS2_ARG_CONV_EXCL for cmd.exe

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24916#pullrequestreview-2802106438

From kvn at openjdk.org  Tue Apr 29 06:27:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 06:27:41 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v10]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <HqOlWJ_Ybtgd8y-5SKlLGItwtYybwQDCqwoL-Th3gsM=.7d71ca03-8f8d-4c97-9a07-be920638b70a@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fix C strings caching
 - Merge branch 'master' into JDK-8350209
 - Merge branch 'master' into JDK-8350209
 - Downgraded UL as asked. Added synchronization to C strings caching.
 - Fix message
 - Generate far jumps for AOT code on AArch64
 - remove _enabled suffix
 - Add sanity test for AOTAdapterCaching flag
 - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
 - Removed unused AOTCodeSection class
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7cf190fb...1b0c89f6

-------------

Changes: https://git.openjdk.org/jdk/pull/24740/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=09
  Stats: 3314 lines in 51 files changed: 2845 ins; 200 del; 269 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

PR: https://git.openjdk.org/jdk/pull/24740

From kvn at openjdk.org  Tue Apr 29 06:27:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 06:27:42 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v9]
In-Reply-To: <MP-yrnmJU5zCfu-McanoUeKsOvCz9nDT6iWwHUAu4hQ=.a44648cc-a05a-450a-9d89-cabeecf0bdcb@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>
 <MP-yrnmJU5zCfu-McanoUeKsOvCz9nDT6iWwHUAu4hQ=.a44648cc-a05a-450a-9d89-cabeecf0bdcb@github.com>
Message-ID: <bZKvq_YX9Eu50fYO7X2nqR0Aex2jydIp1X4OC7j6Uw0=.b315144b-fb05-46f2-8334-0562d54805a9@github.com>

On Mon, 28 Apr 2025 20:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge branch 'master' into JDK-8350209
>>  - Downgraded UL as asked. Added synchronization to C strings caching.
>>  - Fix message
>>  - Generate far jumps for AOT code on AArch64
>>  - remove _enabled suffix
>>  - Add sanity test for AOTAdapterCaching flag
>>  - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
>>  - Removed unused AOTCodeSection class
>>  - 8350209: Preserve adapters in AOT cache
>
> Build change is trivially fine.

Thank you, @magicus, for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2837612510

From kvn at openjdk.org  Tue Apr 29 06:27:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 06:27:43 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v9]
In-Reply-To: <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <T-bZvgRg5k3teUL6x3BeDhXlEUM2DZ951UpJk-hXlrw=.54594630-45b2-41ef-9647-0bef700fd58f@github.com>
Message-ID: <ei7sWKfN16dh5aD7MfmM6oo_id392kSz3nqPKdK8X_o=.371b6bfa-ba26-491d-a3c3-126aa004e79a@github.com>

On Sun, 27 Apr 2025 22:22:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into JDK-8350209
>  - Downgraded UL as asked. Added synchronization to C strings caching.
>  - Fix message
>  - Generate far jumps for AOT code on AArch64
>  - remove _enabled suffix
>  - Add sanity test for AOTAdapterCaching flag
>  - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
>  - Removed unused AOTCodeSection class
>  - 8350209: Preserve adapters in AOT cache

Did new merge from mainline and fixed C strings caching issue found in `leyden/premain` branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2837614987

From ihse at openjdk.org  Tue Apr 29 06:46:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Apr 2025 06:46:51 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
Message-ID: <U6Tb7ziW1SZElRzQKIfRepViZ4ofLQs-beS2f9NpzPI=.e29e8eb2-62fb-48e1-a8bf-4a52f66db2e2@github.com>

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>  - Address henryjen@ comment:
>    - Remove '#include <jni.h>'.

This was news to me. I'm thinking about what this means in terms of the static build, where all native JDK libraries are "loaded" as soon as the application starts executing. Do we have native libraries in the JDK that are not loaded by the boot loader? If so, have we introduced some corner case effects by marking them with the static JNI symbol? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837654312

From matthias.baesken at sap.com  Tue Apr 29 07:11:57 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Apr 2025 07:11:57 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
Message-ID: <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>

  *   I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-)
Yeah I looked into msan some time ago and wanted to look into it again  now .


  *   I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler?

I think so !  When I build a simple (working) example with msan   (clang++ -fsanitize=memory    in complie and link step, no libs added), I get a LOT of msan symbols in the resulting binary  :

nm msan_umr  | grep _msan  | more
00000000000221a0 t _GLOBAL__sub_I_msan_chained_origin_depot.cpp
0000000000057520 T __msan_allocated_memory
000000000004c5c0 T __msan_chain_origin
000000000004c2b0 T __msan_check_mem_is_initialized
0000000000093200 T __msan_clear_and_unpoison
000000000004c020 T __msan_clear_on_return
0000000000057600 T __msan_copy_shadow
000000000004cb50 W __msan_default_options
000000000004c150 T __msan_dump_shadow
000000000004ca60 T __msan_finish_switch_fiber
000000000004c3c0 T __msan_get_origin
000000000004ade0 T __msan_get_track_origins
000000000004c710 T __msan_get_umr_origin
   ....

  *   Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.


Sounds like a good idea to start with, I will try this!   Seems the visibility stuff plays a role here.

Best regards, Matthias


From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Monday, 28 April 2025 22:06
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.org
Subject: Re: clang Memory sanitizer (msan) and OpenJDK


I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-)

https://mail.openjdk.org/pipermail/build-dev/2024-August/046011.html

I guess nobody still has a simple answer to give you. I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler?

Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.

/Magnus
On 2025-04-25 16:28, Baesken, Matthias wrote:
Hi,  Memory sanitizer
https://clang.llvm.org/docs/MemorySanitizer.html

is supported with the clang toolchain  (e.g. on Linux) ;  ?MemorySanitizer is a detector of uninitialized memory use?  .

For small examples it is rather easy to use,   you just compile and link   with   -fsanitize=memory      (and for better results maybe additionally  -fno-omit-frame-pointer )   .

So I gave it a try with OpenJDK too and added   -fsanitize=memory      to the  C/CXX and LD flags  (--with-extra-cflags=-fsanitize=memory --with-extra-cxxflags=-fsanitize=memory --with-extra-ldflags=-fsanitize=memory ).
As far as compiling single  compilation units this seems to be okay .
But when it comes to executing the new generated binaries in the build process  we unfortunately  get  lookup errors / undefined symbols   :

/builddir/jdk/bin/javac: symbol lookup error:  /builddir/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls


Is there something special in our OpenJDK  build that causes trouble here ?


Here I found an somewhat similar looking issue :
https://groups.google.com/g/memory-sanitizer/c/xV3OZZCiL9A

where re-exporting symbols is mentioned -  is this maybe something that hits us in OpenJDK too ?


For address sanitizer, we set  -shared-libasan in the OpenJDK :

https://github.com/openjdk/jdk/blob/5c067232bf21aaca2b7addd2a862e15a8696ffb8/make/autoconf/jdk-options.m4#L449
ASAN_LDFLAGS="$ASAN_LDFLAGS -shared-libasan"

But I could not find something similar for msan .


(btw. I use clang 15.0.7 on SUSE Linux x86_64 in case this matters)


Best regards, Matthias







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250429/4b382f19/attachment-0001.htm>

From alanb at openjdk.org  Tue Apr 29 07:57:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Apr 2025 07:57:53 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <U6Tb7ziW1SZElRzQKIfRepViZ4ofLQs-beS2f9NpzPI=.e29e8eb2-62fb-48e1-a8bf-4a52f66db2e2@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <U6Tb7ziW1SZElRzQKIfRepViZ4ofLQs-beS2f9NpzPI=.e29e8eb2-62fb-48e1-a8bf-4a52f66db2e2@github.com>
Message-ID: <6I7C4_Tn-A5rW6VOjZreazlljB4JYH4_2KQpH2oAgy8=.ef149511-c081-4503-9af4-80dc397afb3e@github.com>

On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Do we have native libraries in the JDK that are not loaded by the boot loader? 

There are few, e.g. java.security.jgss, jdk.security.auth and jdk.crypto.cryptoki are mapped to the platform class loader, and jdk.attach mapped to the application class loader.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837849469

From duke at openjdk.org  Tue Apr 29 08:03:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Apr 2025 08:03:47 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v3]
In-Reply-To: <qg6te_c7wTE8JUIVZrbTDhbigCq-EPTaBpOfH7_9KoM=.2b257b0b-c41f-4a19-b034-279e9975556a@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <qg6te_c7wTE8JUIVZrbTDhbigCq-EPTaBpOfH7_9KoM=.2b257b0b-c41f-4a19-b034-279e9975556a@github.com>
Message-ID: <mR_2NuaDMXIzxBDnWbjbFFhSlS7sXnH3rMx6jN8StJQ=.1ffd1bf1-3aeb-4cbc-813a-fd8938eac191@github.com>

On Tue, 29 Apr 2025 03:38:33 GMT, kuaiwei <duke at openjdk.org> wrote:

>> The patch fix error when creating devkit on wsl/msys2 .
>> * Msys2 can be supported like cygwin
>> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
>> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
>> 
>> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)
>
> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support more msys2 environments and use MSYS2_ARG_CONV_EXCL for cmd.exe

@kuaiwei 
Your change (at version a81a294e7d6a6630604c03e72f7adfe7565ff9b9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2837862847

From duke at openjdk.org  Tue Apr 29 08:19:48 2025
From: duke at openjdk.org (kuaiwei)
Date: Tue, 29 Apr 2025 08:19:48 GMT
Subject: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
In-Reply-To: <wryu33n7Mm9pWK8pJHSUniWBviFCGx6zTlMPEBfVfpU=.e18ff7df-dea0-43ef-bfca-4350f9850111@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
 <nOJqvP2bpfrQilQk8G2hHqljjJz9JzQPDh-9GCCRIsA=.ffa56ea5-8ff9-4a92-8cf5-8bb6d2570b13@github.com>
 <wryu33n7Mm9pWK8pJHSUniWBviFCGx6zTlMPEBfVfpU=.e18ff7df-dea0-43ef-bfca-4350f9850111@github.com>
Message-ID: <AigcSCOFjvQ0sO30LKcG0f2fUmUQj5fGbjMxsoWi7YQ=.3e6ddbe2-b522-4af2-b6c5-d4f3e6054604@github.com>

On Mon, 28 Apr 2025 13:47:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> kuaiwei has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get SDK_INSTALL_DIR from enviroment variable
>
> Verified that it still works in Cygwin on my machine. Looks good.

@erikj79 @magicus Thanks for your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2837899304

From duke at openjdk.org  Tue Apr 29 08:34:00 2025
From: duke at openjdk.org (kuaiwei)
Date: Tue, 29 Apr 2025 08:34:00 GMT
Subject: Integrated: 8355697: Create windows devkit on wsl and msys2
In-Reply-To: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
References: <gJ_5ybrwZYals5PpqLSfa8q1z10_asCQuk5_l0R4Y9g=.1376f9d7-d0e6-4a0c-a5d9-d7a2fa8b4ab0@github.com>
Message-ID: <rCKwfMexg8POEN7X7_CtpfYrW7AiRY9LkG_ETkggiAY=.0da874bd-5e66-4af1-b047-82177f7aa646@github.com>

On Mon, 28 Apr 2025 11:03:16 GMT, kuaiwei <duke at openjdk.org> wrote:

> The patch fix error when creating devkit on wsl/msys2 .
> * Msys2 can be supported like cygwin
> * In wsl, it can not test path name in windows format, like `if [ -d "d:/VisualStuio"]` . The path must be converted as linux style before testing.
> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it can be work around with `cmd.exe //c`. see https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell
> 
> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6)

This pull request has now been integrated.

Changeset: 31e70e41
Author:    Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31e70e41d56777ba6f4bba4cc3266130646b3202
Stats:     17 lines in 1 file changed: 12 ins; 0 del; 5 mod

8355697: Create windows devkit on wsl and msys2

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/24916

From mbaesken at openjdk.org  Tue Apr 29 09:05:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 09:05:07 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan [v2]
In-Reply-To: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
Message-ID: <tdESYTZCQyWOGGKDhNLlEQyro9ow2-HwklT2JYMIxrg=.9ff717ef-bd4d-454d-9d20-c81a35ab855f@github.com>

> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
> 
> 
> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Sort flags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24924/files
  - new: https://git.openjdk.org/jdk/pull/24924/files/dbfcece2..72bec244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24924&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24924&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24924/head:pull/24924

PR: https://git.openjdk.org/jdk/pull/24924

From mbaesken at openjdk.org  Tue Apr 29 09:05:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 09:05:08 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan [v2]
In-Reply-To: <yd7SsUYYHd2IHo3Qo_Yu84R5xvEyeN5Z5EUjzlqSCeQ=.c54ca964-2942-47ea-9efe-81c286eb3f38@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
 <yd7SsUYYHd2IHo3Qo_Yu84R5xvEyeN5Z5EUjzlqSCeQ=.c54ca964-2942-47ea-9efe-81c286eb3f38@github.com>
Message-ID: <eYXaoILt3oSp5mwS2gxedgy67TmnQyv6tbaMakqBqK4=.1d58a003-c90e-45a8-8a10-a953180bba26@github.com>

On Mon, 28 Apr 2025 19:25:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sort flags
>
> make/autoconf/jdk-options.m4 line 525:
> 
>> 523:   UBSAN_CFLAGS="$UBSAN_CHECKS -Wno-array-bounds -fno-omit-frame-pointer -DUNDEFINED_BEHAVIOR_SANITIZER"
>> 524:   if test "x$TOOLCHAIN_TYPE" = "xgcc"; then
>> 525:     UBSAN_CFLAGS="$UBSAN_CFLAGS -Wno-stringop-truncation -Wno-format-overflow -Wno-stringop-overflow"
> 
> Just for the sake of my sanity, can you reorder the `-Wno-*` options in alphabetical order?

Done !  Need a re-review now .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24924#discussion_r2065839527

From erikj at openjdk.org  Tue Apr 29 13:05:48 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Apr 2025 13:05:48 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan [v2]
In-Reply-To: <tdESYTZCQyWOGGKDhNLlEQyro9ow2-HwklT2JYMIxrg=.9ff717ef-bd4d-454d-9d20-c81a35ab855f@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
 <tdESYTZCQyWOGGKDhNLlEQyro9ow2-HwklT2JYMIxrg=.9ff717ef-bd4d-454d-9d20-c81a35ab855f@github.com>
Message-ID: <vEfEHouvLXT55jwGbPENJ-wQiETcSUGX6gIpVIv_cKM=.0ed38363-f97c-4345-8798-b62f8545533b@github.com>

On Tue, 29 Apr 2025 09:05:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
>> 
>> 
>> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort flags

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24924#pullrequestreview-2803359916

From mbaesken at openjdk.org  Tue Apr 29 13:29:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 13:29:53 GMT
Subject: RFR: 8355594: Warnings occur when building with clang and enabling
 ubsan [v2]
In-Reply-To: <tdESYTZCQyWOGGKDhNLlEQyro9ow2-HwklT2JYMIxrg=.9ff717ef-bd4d-454d-9d20-c81a35ab855f@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
 <tdESYTZCQyWOGGKDhNLlEQyro9ow2-HwklT2JYMIxrg=.9ff717ef-bd4d-454d-9d20-c81a35ab855f@github.com>
Message-ID: <i4J0U_w9B9AleQzYHou5OVA32uYzvEp8o7SRddsFwIA=.3bcbd23f-0e58-47bb-a170-881658713fe1@github.com>

On Tue, 29 Apr 2025 09:05:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
>> 
>> 
>> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
>> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort flags

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24924#issuecomment-2838910357

From mbaesken at openjdk.org  Tue Apr 29 13:29:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 13:29:54 GMT
Subject: Integrated: 8355594: Warnings occur when building with clang and
 enabling ubsan
In-Reply-To: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
References: <SqjkoCiuqR7DVPkXiwCAHcHoMjOJjQ79Dk78fwi6KDg=.47a855a3-0202-4be0-9323-f20a78ea8673@github.com>
Message-ID: <sj_1XOsUoXVHo9psEbijnkFrGmTVYcbSW2re015WIbU=.dc91a29a-643c-40d6-ac08-64a8192537ef@github.com>

On Mon, 28 Apr 2025 15:22:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or Linux), we get the following warnings :
> 
> 
> warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-format-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]

This pull request has now been integrated.

Changeset: 9f42ff89
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f42ff8960c740fa6ae5be21677b874463c7f500
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8355594: Warnings occur when building with clang and enabling ubsan

Reviewed-by: erikj, jkern, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/24924

From matthias.baesken at sap.com  Tue Apr 29 13:56:43 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Apr 2025 13:56:43 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
 <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <AM9PR02MB67703703095231ED1E5A5B2293802@AM9PR02MB6770.eurprd02.prod.outlook.com>

>>Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.
>Sounds like a good idea to start with, I will try this!   Seems the visibility stuff plays a role here.

I removed  the  -fvisibility=hidden  from  make/autoconf/flags-cflags.m4   (3 places)  but the issue is still there.
When looking at our launchers in the msan ? enabled build   (java, javac)  I see the  msan_param_tls   as  ?b?      (local symbol)  .
But I think it is expected as ?B?   (global/exported) .
In my simple working  standalone example, the  msan_param_tls   is ?B? .
So there must be something in out build  that prevents the  ?export?  of those msan  symbols (even when removing -fvisibility=hidden  ) .
Probably I should look in more details at our launcher builds and all the settings ...

Best regards, Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250429/7e19607f/attachment-0001.htm>

From asmehra at openjdk.org  Tue Apr 29 14:46:51 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Apr 2025 14:46:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v8]
In-Reply-To: <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>
Message-ID: <FxHe56_j8Eo1Z1f8y1AlFpucgFay1RfW-ZrlF3mpaR8=.ab047ccb-d7c1-4dbd-a912-5562d7d6bb8c@github.com>

On Sun, 27 Apr 2025 21:52:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Downgraded UL as asked. Added synchronization to C strings caching.

src/hotspot/share/code/aotCodeCache.hpp line 340:

> 338:   static const char* add_C_string(const char* str) NOT_CDS_RETURN_(str);
> 339: 
> 340: static const char* add_C_string2(const char* str) NOT_CDS_RETURN_(str);

This method is not used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2066731291

From matthias.baesken at sap.com  Tue Apr 29 14:47:51 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Apr 2025 14:47:51 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <AM9PR02MB67703703095231ED1E5A5B2293802@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
 <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB67703703095231ED1E5A5B2293802@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <AM9PR02MB67709E2EB1DEA97E42A5805393802@AM9PR02MB6770.eurprd02.prod.outlook.com>

I checked the link call for  javac .

/usr/bin/clang -fuse-ld=lld -fuse-ld=lld     -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -fsanitize=memory   ....

Could it be that the  -Wl,--exclude-libs,ALL    ?hides?  the  msan symbols like   __msan_param_tls    from exporting ?
But I guess we set this for a reason so removing it might cause other trouble ?

Best regards, Matthias


----------------------------------------------------
>>Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.
>Sounds like a good idea to start with, I will try this!   Seems the visibility stuff plays a role here.

I removed  the  -fvisibility=hidden  from  make/autoconf/flags-cflags.m4   (3 places)  but the issue is still there.
When looking at our launchers in the msan ? enabled build   (java, javac)  I see the  msan_param_tls   as  ?b?      (local symbol)  .
But I think it is expected as ?B?   (global/exported) .
In my simple working  standalone example, the  msan_param_tls   is ?B? .
So there must be something in out build  that prevents the  ?export?  of those msan  symbols (even when removing -fvisibility=hidden  ) .
Probably I should look in more details at our launcher builds and all the settings ...

Best regards, Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250429/65a007c0/attachment-0001.htm>

From asmehra at openjdk.org  Tue Apr 29 14:49:51 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Apr 2025 14:49:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v10]
In-Reply-To: <HqOlWJ_Ybtgd8y-5SKlLGItwtYybwQDCqwoL-Th3gsM=.7d71ca03-8f8d-4c97-9a07-be920638b70a@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <HqOlWJ_Ybtgd8y-5SKlLGItwtYybwQDCqwoL-Th3gsM=.7d71ca03-8f8d-4c97-9a07-be920638b70a@github.com>
Message-ID: <yTzXKxaW63eOD3tMHK9VJoehzbdII0MT9UGti4CasQU=.3a8910f0-4e15-41ee-b129-8be7d65d19b8@github.com>

On Tue, 29 Apr 2025 06:27:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix C strings caching
>  - Merge branch 'master' into JDK-8350209
>  - Merge branch 'master' into JDK-8350209
>  - Downgraded UL as asked. Added synchronization to C strings caching.
>  - Fix message
>  - Generate far jumps for AOT code on AArch64
>  - remove _enabled suffix
>  - Add sanity test for AOTAdapterCaching flag
>  - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
>  - Removed unused AOTCodeSection class
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7cf190fb...1b0c89f6

Just to note there is still some code related to blobs but we are not storing them yet in the aot code cache. But I think we would need them pretty soon. So I think it should be okay to keep that code as is.

rest lgtm

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839210239
PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839211140

From kvn at openjdk.org  Tue Apr 29 15:29:08 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 15:29:08 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v11]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/1b0c89f6..b2466e6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

PR: https://git.openjdk.org/jdk/pull/24740

From kvn at openjdk.org  Tue Apr 29 15:29:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 15:29:16 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v8]
In-Reply-To: <FxHe56_j8Eo1Z1f8y1AlFpucgFay1RfW-ZrlF3mpaR8=.ab047ccb-d7c1-4dbd-a912-5562d7d6bb8c@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <I3z3_bHAu2K56uPY65Z7vxOHqex0qX4g1F-pssj60Gc=.1f15a378-6fdf-4e28-bf5c-b17fbe58bed8@github.com>
 <FxHe56_j8Eo1Z1f8y1AlFpucgFay1RfW-ZrlF3mpaR8=.ab047ccb-d7c1-4dbd-a912-5562d7d6bb8c@github.com>
Message-ID: <WSoAeMoG6NdjlfmDA5w01UaK9atETsgxSFagX3NA6L0=.90d48584-0cb6-4120-a075-0eb6edddbc28@github.com>

On Tue, 29 Apr 2025 14:42:42 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Downgraded UL as asked. Added synchronization to C strings caching.
>
> src/hotspot/share/code/aotCodeCache.hpp line 340:
> 
>> 338:   static const char* add_C_string(const char* str) NOT_CDS_RETURN_(str);
>> 339: 
>> 340: static const char* add_C_string2(const char* str) NOT_CDS_RETURN_(str);
> 
> This method is not used.

removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2066822894

From asmehra at openjdk.org  Tue Apr 29 15:40:56 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 29 Apr 2025 15:40:56 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v11]
In-Reply-To: <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>
Message-ID: <Hpspf3AzYvpQPcntc8CwzERRMoyiKV2xLlhdCzTBmUk=.e709907a-0723-40f6-af65-7ea665286fdd@github.com>

On Tue, 29 Apr 2025 15:29:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused method

Marked as reviewed by asmehra (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2804162746

From jwaters at openjdk.org  Tue Apr 29 15:41:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Apr 2025 15:41:02 GMT
Subject: RFR: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <J9PeKoaqBDZCnarUN_ikXoY_L5bNI_OZZlXzkhU7xpw=.037c7439-3edf-4755-91b5-904748190f5b@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

To address Sergey's concerns, testing on my end _seems_ to indicate that it does inherit the whitespace option. Since this is not a serious breaking change, I'm going to integrate it. If it turns out to break editor formatting for someone somewhere, we can easily back this out later

Oops, before I integrate, this should have the ide-support flag too

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2839366874
PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2839369944

From jwaters at openjdk.org  Tue Apr 29 15:41:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Apr 2025 15:41:02 GMT
Subject: Integrated: 8354919: Move HotSpot .editorconfig into the global
 .editorconfig
In-Reply-To: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
References: <YNeNhtX_fr-N8nEfdMV0tNc_IAwTCU_ypvXYX_vZyec=.2a0f4858-cfce-4350-950c-436248cad08c@github.com>
Message-ID: <3DviS8uB6Ob0amR92RBdjORmWGngsT61iUeGt640tWY=.26ba3aa3-9aa5-4c52-b6a8-e412a96371e9@github.com>

On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig

This pull request has now been integrated.

Changeset: fa2a9d1e
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa2a9d1e10679aad270f4641f43595b36fe8e04c
Stats:     7 lines in 2 files changed: 4 ins; 3 del; 0 mod

8354919: Move HotSpot .editorconfig into the global .editorconfig

Reviewed-by: erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/24714

From matthias.baesken at sap.com  Tue Apr 29 15:44:59 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 29 Apr 2025 15:44:59 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <AM9PR02MB67709E2EB1DEA97E42A5805393802@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
 <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB67703703095231ED1E5A5B2293802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB67709E2EB1DEA97E42A5805393802@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <AM9PR02MB6770231B4200BA924CAE3CDE93802@AM9PR02MB6770.eurprd02.prod.outlook.com>

>Could it be that the  -Wl,--exclude-libs,ALL    ?hides?  the  msan symbols like   __msan_param_tls    from exporting ?
>But I guess we set this for a reason so removing it might cause other trouble ?

Seems the -Wl,--exclude-libs,ALL     is the setting that caused the msan build issue, when I remove  it the build works until the first  ?new? binary is executed and runs into  :

==64305==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7fbe17639b01  (/builddir/jdk/lib/server/libjvm.so+0x246bb01) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #1 0x7fbe18ba4751  (/builddir/jdk/lib/server/libjvm.so+0x39d6751) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #2 0x7fbe17489e64  (/builddir/jdk/lib/server/libjvm.so+0x22bbe64) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #3 0x7fbe18bc90ab  (/builddir/jdk/lib/server/libjvm.so+0x39fb0ab) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #4 0x7fbe176e695b  (/builddir/jdk/lib/server/libjvm.so+0x251895b) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #5 0x7fbe1ae182d8  (/builddir/jdk/bin/../lib/libjli.so+0x112d8) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5)
    #6 0x7fbe1ae23358  (/builddir/jdk/bin/../lib/libjli.so+0x1c358) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5)
    #7 0x7fbe1add06e9  (/lib64/libpthread.so.0+0xa6e9) (BuildId: 938e42b7e407d175ee3ef9a89c038168101d330c)
    #8 0x7fbe1ab4558e  (/lib64/libc.so.6+0x11858e) (BuildId: 74f77bf013a66413c77197c121955e029c32d259)


Unfortunately the functions and line numbers from the backtrace are not (yet) nicely displayed , guess this needs some improvement .
When calling addr2line on  libjvm.so with the last address from the stack , I get   jfrThreadLocal.cpp:81  .

Best regards, Matthias






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250429/0341f4c9/attachment-0001.htm>

From kvn at openjdk.org  Tue Apr 29 16:08:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Apr 2025 16:08:59 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v10]
In-Reply-To: <yTzXKxaW63eOD3tMHK9VJoehzbdII0MT9UGti4CasQU=.3a8910f0-4e15-41ee-b129-8be7d65d19b8@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <HqOlWJ_Ybtgd8y-5SKlLGItwtYybwQDCqwoL-Th3gsM=.7d71ca03-8f8d-4c97-9a07-be920638b70a@github.com>
 <yTzXKxaW63eOD3tMHK9VJoehzbdII0MT9UGti4CasQU=.3a8910f0-4e15-41ee-b129-8be7d65d19b8@github.com>
Message-ID: <WGDSHSzFf4zDltspFq--tNkiVLf7Kwd3cZYO4mtqvBY=.0c2dcd0f-80b9-4a9a-aeb5-20810a083bb0@github.com>

On Tue, 29 Apr 2025 14:47:42 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Fix C strings caching
>>  - Merge branch 'master' into JDK-8350209
>>  - Merge branch 'master' into JDK-8350209
>>  - Downgraded UL as asked. Added synchronization to C strings caching.
>>  - Fix message
>>  - Generate far jumps for AOT code on AArch64
>>  - remove _enabled suffix
>>  - Add sanity test for AOTAdapterCaching flag
>>  - AOT code flags are ignored when AOTCache is not specified. Set range for AOTCodeMaxSize values.
>>  - Removed unused AOTCodeSection class
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7cf190fb...1b0c89f6
>
> rest lgtm

Thank you, @ashu-mehra, for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839457011

From jiangli at openjdk.org  Tue Apr 29 21:39:50 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 29 Apr 2025 21:39:50 GMT
Subject: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find()
 doesn't work on static JDK [v3]
In-Reply-To: <U6Tb7ziW1SZElRzQKIfRepViZ4ofLQs-beS2f9NpzPI=.e29e8eb2-62fb-48e1-a8bf-4a52f66db2e2@github.com>
References: <YUY3eN8kAmCQq595LNfoPjsuzDg9V69TSC8uY-dw3cg=.5a650605-ea72-4b13-a94b-518c2e577be0@github.com>
 <6FEh_BU-bEnPSi3VfsouNChNmIJwlV5yKOOW4cMVqVw=.849fab0f-289f-4420-a79a-c4b7c37b8a96@github.com>
 <U6Tb7ziW1SZElRzQKIfRepViZ4ofLQs-beS2f9NpzPI=.e29e8eb2-62fb-48e1-a8bf-4a52f66db2e2@github.com>
Message-ID: <7dQZdXM5rw2AAwubnEkRaJhiGPzNDzFDmSRVrEnEa_g=.5011ef91-af54-404d-84a5-e252778fe935@github.com>

On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into JDK-8355080
>>  - Address henryjen@ comment:
>>    - Remove '#include <jni.h>'.
>
> This was news to me. I'm thinking about what this means in terms of the static build, where all native JDK libraries are "loaded" as soon as the application starts executing. Do we have native libraries in the JDK that are not loaded by the boot loader? If so, have we introduced some corner case effects by marking them with the static JNI symbol? ?

@magicus For existing JDK JNI native libraries, I think adding `DEF_STATIC_JNI_OnLoad` (if missing) does not affect the classloader usage associated with the library. The static support for built-in JNI native library affects the native "load" operation (e.g. on Linux `dlopen`) only ([Java_jdk_internal_loader_NativeLibraries_load](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L119). Double checking [Java_jdk_internal_loader_NativeLibraries_unload](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L180), the existing code also makes sure `JVM_UnloadLibrary` is not called to "unload" (e.g. on Linux `dlclose`) built-in JNI native library.

The reason why boot loader question/consideration brought up in this thread was because `libsyslookup` was not associated with the boot loader but now does with the change in src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2840305879

From iklam at openjdk.org  Wed Apr 30 01:17:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 01:17:57 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v11]
In-Reply-To: <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>
Message-ID: <YbwRKz5qGuuPOLrrH4JltOcfQNuOd84O7_refQhkw3k=.0f1658fe-17a0-487a-b558-787013a9936d@github.com>

On Tue, 29 Apr 2025 15:29:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused method

LGTM. Some small nits.

src/hotspot/share/cds/filemap.cpp line 1296:

> 1294:     mapped_base = requested_base;
> 1295:   } else {
> 1296:     bool read_only = false, allow_exec = false;

Add comment for clarity:


// We do not execute in-place in the AOT code region. AOT code is copied to
// the CodeCache for execution.
bool read_only = false, allow_exec = false;

src/hotspot/share/include/cds.h line 38:

> 36: // Also, this is a C header file. Do not use C++ here.
> 37: 
> 38: #define NUM_CDS_REGIONS 5 // this must be the same as MetaspaceShared::n_regions

Change `CURRENT_CDS_ARCHIVE_VERSION` below to `19`

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2805483199
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2067701064
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2067702057

From kvn at openjdk.org  Wed Apr 30 02:05:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Apr 2025 02:05:41 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v12]
In-Reply-To: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
Message-ID: <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>

> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
> 
> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
> 
> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
> 
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
> 
> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
> 
> 
> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
> 
> 
> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
> 
> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
> This flag is ignored when `AOTCache` is not specified.
> 
> To use AOT adapters follow process described in JEP 483:
> 
> 
> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
> java -XX:AOTCache=app.aot -cp app.jar App
> 
> 
> There are several new UL flag combinations to trace the AOT code caching process:
> 
> 
> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
> 
> 
> @ashu-mehra is main author of changes. He implemented adapters caching.
> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
> 
> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  address Ioi's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24740/files
  - new: https://git.openjdk.org/jdk/pull/24740/files/b2466e6e..78f2828d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=10-11

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740

PR: https://git.openjdk.org/jdk/pull/24740

From kvn at openjdk.org  Wed Apr 30 02:05:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Apr 2025 02:05:42 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v11]
In-Reply-To: <YbwRKz5qGuuPOLrrH4JltOcfQNuOd84O7_refQhkw3k=.0f1658fe-17a0-487a-b558-787013a9936d@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <gQXByQyrpk0CZDVq2NGU8GzDmqLJDqIwdy0-K7E5kxM=.37b25b7b-0598-43d5-9d95-8347d6c90d3d@github.com>
 <YbwRKz5qGuuPOLrrH4JltOcfQNuOd84O7_refQhkw3k=.0f1658fe-17a0-487a-b558-787013a9936d@github.com>
Message-ID: <yY7mA5UruDloCRy23nJyJyVLA7SeOjzMq94DkbzKI3w=.d8f8acb8-f1c8-4cde-a01d-092921ad0e13@github.com>

On Wed, 30 Apr 2025 01:15:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused method
>
> LGTM. Some small nits.

Thank you, @iklam, for review. I pushed your suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2840619267

From iklam at openjdk.org  Wed Apr 30 02:45:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Apr 2025 02:45:48 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v12]
In-Reply-To: <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
Message-ID: <m73YXLA-Cvcf4BxcNauspbztMHXzGCHS6EzN1sQ0MJ4=.f53a71bf-3f4a-4cf8-a863-d658c5d30986@github.com>

On Wed, 30 Apr 2025 02:05:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address Ioi's comments

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2805579280

From amitkumar at openjdk.org  Wed Apr 30 04:16:44 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 30 Apr 2025 04:16:44 GMT
Subject: RFR: 8355570: [s390x] Update -march to z13 generation
In-Reply-To: <MzQei2wdmgB1n0dlofT5m5uVnyZmijXaraYE1X8UAxk=.03e72917-918f-4ce7-a840-a1992cb840d6@github.com>
References: <BNeZYs7djrqpSf0b8BCH3aVujUkmHwSQezuNmPYH82s=.e3fc0b55-2886-46b9-bf05-784f87a77a15@github.com>
 <MzQei2wdmgB1n0dlofT5m5uVnyZmijXaraYE1X8UAxk=.03e72917-918f-4ce7-a840-a1992cb840d6@github.com>
Message-ID: <jZ7B_kwIR5yVEJxARDmxa3SZSrgqoFIM-VsNR_jSFKg=.5527eefe-c68d-4412-8991-38a4f86b2e2a@github.com>

On Mon, 28 Apr 2025 19:35:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a failure when building the gtest framework.
> 
> Could this different arch flag be sensitive to different gcc versions? When you say you tested locally, what gcc version did you use?

This is the config: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2840757074

From iveresov at openjdk.org  Wed Apr 30 05:39:04 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 05:39:04 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v5]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <KBJS-cV2SILVKvfeg73VtkVH65wYLzwDHYR8W_kcDNQ=.e4d208d7-c408-4cfa-b6b1-fdb1c8629a92@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Address review comments part 2
 - Merge branch 'master' into pp2
 - Merge branch 'master' into pp2
 - Fix class filtering
 - Remove the workaround of setting AOTRecordTraining during assembly
 - Address some of the review comments
 - Merge branch 'master' into pp
 - Add AOTCompileEagerly flag to control compilation after clinit
 - Port 8355334: [leyden] Missing type profile info in archived training data
 - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
 - ... and 24 more: https://git.openjdk.org/jdk/compare/6850757f...4514d032

-------------

Changes: https://git.openjdk.org/jdk/pull/24886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=04
  Stats: 3197 lines in 57 files changed: 2972 ins; 103 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Wed Apr 30 05:39:04 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 05:39:04 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v5]
In-Reply-To: <PldUCKo1RdxtOCfhei3_LXO8A87wWRZWQqSfsLDtTpk=.b2b4fc88-bb6b-4676-a807-a17473d5adb6@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
 <OoJZKZbihUQBUDK85cTK16sQQUtcAbdY-R5sntQ8zaQ=.9f20e0b4-c2ed-440a-858e-4486e4c0acc2@github.com>
 <PldUCKo1RdxtOCfhei3_LXO8A87wWRZWQqSfsLDtTpk=.b2b4fc88-bb6b-4676-a807-a17473d5adb6@github.com>
Message-ID: <2b3hUB0FEH3l0nU-C6rkeihJwHawxzfkHI3UVbGfO88=.dc289b11-8c83-4473-96fb-40381c986c59@github.com>

On Sun, 27 Apr 2025 01:15:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> You mean you want these checks to be done only if `TrainingData::have_data() == true` ?
>
> Yes, if it is related. Otherwise you may change default behavior when Leyden code is not used.

I simplified it and factored out the new semantics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2067883564

From galder at openjdk.org  Wed Apr 30 08:41:45 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 30 Apr 2025 08:41:45 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <Ett3UTOEuxrfiOFXWoJz8CeSACuYNR-WobLGw3iuyoU=.7b3a9042-15d2-467a-bcb2-b09c0e1e344b@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
 <tZmRl-xQKEOJNNGwz-FJPMhrXfjhgGPJwI9qsTaA5e4=.e9dfc1e6-66f7-4c35-a9e6-db85fb62eef4@github.com>
 <Ett3UTOEuxrfiOFXWoJz8CeSACuYNR-WobLGw3iuyoU=.7b3a9042-15d2-467a-bcb2-b09c0e1e344b@github.com>
Message-ID: <uTnvnBj_oa8fjUE9PdSKMHqnSH_s7DrZH6A786Gc7r0=.c1fda757-2c70-4bfc-be03-b27f4aed947f@github.com>

On Mon, 28 Apr 2025 23:10:27 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I do think it's a bug that JMH is bundling its checkstyle and findbugs configurations in its distribution jar, so perhaps we can suggest to a JMH maintainer to stop doing that. :)

I think that makes sense to me and I can try to do that. Both files could be moved to `src/test/resources`, modify the jmh-core pom.xml to files there instead. The combination of both would stop those xml from ending in the distribution jar.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2841239517

From galder at openjdk.org  Wed Apr 30 08:45:47 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 30 Apr 2025 08:45:47 GMT
Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH
 benchmarks
In-Reply-To: <uTnvnBj_oa8fjUE9PdSKMHqnSH_s7DrZH6A786Gc7r0=.c1fda757-2c70-4bfc-be03-b27f4aed947f@github.com>
References: <oODgYcRdU8Z9R1WT_KflYiejZToN-aaOMI-9SVDOhbA=.0a2d4b01-1506-4441-8149-7527dad45dd8@github.com>
 <tZmRl-xQKEOJNNGwz-FJPMhrXfjhgGPJwI9qsTaA5e4=.e9dfc1e6-66f7-4c35-a9e6-db85fb62eef4@github.com>
 <Ett3UTOEuxrfiOFXWoJz8CeSACuYNR-WobLGw3iuyoU=.7b3a9042-15d2-467a-bcb2-b09c0e1e344b@github.com>
 <uTnvnBj_oa8fjUE9PdSKMHqnSH_s7DrZH6A786Gc7r0=.c1fda757-2c70-4bfc-be03-b27f4aed947f@github.com>
Message-ID: <YXZXZrpjK_VXGKLu9mMcB31QhFEHNnDjhOyurlm7w7g=.93c0e010-7839-4d66-9949-fdb224e1f792@github.com>

On Wed, 30 Apr 2025 08:38:51 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> > I do think it's a bug that JMH is bundling its checkstyle and findbugs configurations in its distribution jar, so perhaps we can suggest to a JMH maintainer to stop doing that. :)
> 
> I think that makes sense to me and I can try to do that. Both files could be moved to `src/test/resources`, modify the jmh-core pom.xml to files there instead. The combination of both would stop those xml from ending in the distribution jar.

I've created [CODETOOLS-7903998](https://bugs.openjdk.org/browse/CODETOOLS-7903998) to track this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2841251130

From matthias.baesken at sap.com  Wed Apr 30 13:28:55 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 30 Apr 2025 13:28:55 +0000
Subject: clang Memory sanitizer (msan) and OpenJDK
In-Reply-To: <AM9PR02MB6770231B4200BA924CAE3CDE93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770D986FF830FD276620ABF93842@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <2f767360-8c81-48f0-8374-344e47865748@oracle.com>
 <AM9PR02MB677048E81F3404B0E5462B9A93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB67703703095231ED1E5A5B2293802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB67709E2EB1DEA97E42A5805393802@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <AM9PR02MB6770231B4200BA924CAE3CDE93802@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <AM9PR02MB6770B94C57A8FBD823BB223D93832@AM9PR02MB6770.eurprd02.prod.outlook.com>

I installed the llvm package to get the   /usr/bin/llvm-symbolizer   (this seems to be needed to get  meaningful stacks) .
Brought back the visibility=hidden settings, seems they do no harm  to msan  .   However the removal  of  -Wl,--exclude-libs,ALL      is needed.
With  the llvm-symbolizer added I get now a stack with file names and  line numbers   (in the build when the new javac is used) :

==81626==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f83267b8121 in JfrThreadLocal::JfrThreadLocal() make/hotspot/src/hotspot/share/jfr/support/jfrThreadLocal.cpp:81:22
    #1 0x7f8327d2e00d in Thread::Thread(MemTag) make/hotspot/src/hotspot/share/runtime/thread.cpp:64:9
    #2 0x7f8326606ef4 in JavaThread::JavaThread(MemTag) make/hotspot/src/hotspot/share/runtime/javaThread.cpp:415:3
    #3 0x7f8327d5347c in Threads::create_vm(JavaVMInitArgs*, bool*) make/hotspot/src/hotspot/share/runtime/threads.cpp:555:33
    #4 0x7f8326865cd2 in JNI_CreateJavaVM_inner(JavaVM_**, void**, void*) make/hotspot/src/hotspot/share/prims/jni.cpp:3587:12
    #5 0x7f8326865cd2 in JNI_CreateJavaVM make/hotspot/src/hotspot/share/prims/jni.cpp:3678:14
    #6 0x7f8329f16008 in InitializeJVM make/src/java.base/share/native/libjli/java.c:1506:9
    #7 0x7f8329f16008 in JavaMain make/src/java.base/share/native/libjli/java.c:494:10
    #8 0x7f8329f21088 in ThreadJavaMain make/src/java.base/unix/native/libjli/java_md.c:646:29
    #9 0x7f8329ecf6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 938e42b7e407d175ee3ef9a89c038168101d330c)
    #10 0x7f8329c4458e in clone (/lib64/libc.so.6+0x11858e) (BuildId: 74f77bf013a66413c77197c121955e029c32d259)

Seems msan is unhappy about the thread != nullptr   in line 81  of  jfrThreadLocal.cpp

  Thread* thread = Thread::current_or_null();
  _parent_trace_id = thread != nullptr ? jvm_thread_id(thread) : (traceid)0;

Not sure why this is reported as  uninitialized ?


Best regards, Matthias



----------------------------------------------------------------------------------------------

>Could it be that the  -Wl,--exclude-libs,ALL    ?hides?  the  msan symbols like   __msan_param_tls    from exporting ?
>But I guess we set this for a reason so removing it might cause other trouble ?

Seems the -Wl,--exclude-libs,ALL     is the setting that caused the msan build issue, when I remove  it the build works until the first  ?new? binary is executed and runs into  :

==64305==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7fbe17639b01  (/builddir/jdk/lib/server/libjvm.so+0x246bb01) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #1 0x7fbe18ba4751  (/builddir/jdk/lib/server/libjvm.so+0x39d6751) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #2 0x7fbe17489e64  (/builddir/jdk/lib/server/libjvm.so+0x22bbe64) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #3 0x7fbe18bc90ab  (/builddir/jdk/lib/server/libjvm.so+0x39fb0ab) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #4 0x7fbe176e695b  (/builddir/jdk/lib/server/libjvm.so+0x251895b) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5)
    #5 0x7fbe1ae182d8  (/builddir/jdk/bin/../lib/libjli.so+0x112d8) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5)
    #6 0x7fbe1ae23358  (/builddir/jdk/bin/../lib/libjli.so+0x1c358) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5)
    #7 0x7fbe1add06e9  (/lib64/libpthread.so.0+0xa6e9) (BuildId: 938e42b7e407d175ee3ef9a89c038168101d330c)
    #8 0x7fbe1ab4558e  (/lib64/libc.so.6+0x11858e) (BuildId: 74f77bf013a66413c77197c121955e029c32d259)


Unfortunately the functions and line numbers from the backtrace are not (yet) nicely displayed , guess this needs some improvement .
When calling addr2line on  libjvm.so with the last address from the stack , I get   jfrThreadLocal.cpp:81  .






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250430/3976379f/attachment-0001.htm>

From liach at openjdk.org  Wed Apr 30 17:38:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 17:38:23 GMT
Subject: RFR: 8355971: Build warnings after the changes for JDK-8354996
Message-ID: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>

There were a few warnings related to illegal native access in HelloClasslist after adding some of the downcall infrastructure. Did a clean build and there were no warning associated with the 

Compiling up to 2 files for CLASSLIST_JAR
Creating support/classlist.jar

steps.

-------------

Commit messages:
 - 8355971: Build warnings after the changes for JDK-8354996

Changes: https://git.openjdk.org/jdk/pull/24970/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355971
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24970/head:pull/24970

PR: https://git.openjdk.org/jdk/pull/24970

From shade at openjdk.org  Wed Apr 30 18:59:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Apr 2025 18:59:44 GMT
Subject: RFR: 8355971: Build warnings after the changes for JDK-8354996
In-Reply-To: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
References: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
Message-ID: <m5AJ7iAMC_lMP7JMse0YO0oog6k-reG6sLzbY7VdaUc=.b5a6f082-7e7e-43a6-8318-da8b31fd4960@github.com>

On Wed, 30 Apr 2025 17:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few warnings related to illegal native access in HelloClasslist after adding some of the downcall infrastructure. Did a clean build and there were no warning associated with the 
> 
> Compiling up to 2 files for CLASSLIST_JAR
> Creating support/classlist.jar
> 
> steps.

Just caught it in my builds. Fix makes sense.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24970#pullrequestreview-2808113806

From erikj at openjdk.org  Wed Apr 30 19:24:44 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 30 Apr 2025 19:24:44 GMT
Subject: RFR: 8355971: Build warnings after the changes for JDK-8354996
In-Reply-To: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
References: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
Message-ID: <2goGs9csh3AUTbaWNDOIFPARZFJ3awl8MLzpAsCKTP4=.e172ce7a-41f1-4e96-a778-8a08f95fc5b9@github.com>

On Wed, 30 Apr 2025 17:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few warnings related to illegal native access in HelloClasslist after adding some of the downcall infrastructure. Did a clean build and there were no warning associated with the 
> 
> Compiling up to 2 files for CLASSLIST_JAR
> Creating support/classlist.jar
> 
> steps.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24970#pullrequestreview-2808171877

From liach at openjdk.org  Wed Apr 30 19:28:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 19:28:49 GMT
Subject: RFR: 8355971: Build warnings after the changes for JDK-8354996
In-Reply-To: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
References: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
Message-ID: <K_RxRGsTf_0aCt0IJspxj6dhio6hP3y80orK2B-M8gc=.19ca9ccd-836c-4af9-95da-4cfc20b77563@github.com>

On Wed, 30 Apr 2025 17:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few warnings related to illegal native access in HelloClasslist after adding some of the downcall infrastructure. Did a clean build and there were no warning associated with the 
> 
> Compiling up to 2 files for CLASSLIST_JAR
> Creating support/classlist.jar
> 
> steps.

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24970#issuecomment-2843058452

From liach at openjdk.org  Wed Apr 30 19:28:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Apr 2025 19:28:49 GMT
Subject: Integrated: 8355971: Build warnings after the changes for JDK-8354996
In-Reply-To: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
References: <m_7WlcDhQLep3MYVID312i08HamSB9x5KHybm5HBWfw=.4e1e3ee5-6edc-4259-8e00-e0dc3831ed39@github.com>
Message-ID: <angNUUq7axdA1hrCvLiWeTPJS1si-ebnIr_odrm8I54=.41333cff-a121-4a64-94f0-48e55f0ff393@github.com>

On Wed, 30 Apr 2025 17:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> There were a few warnings related to illegal native access in HelloClasslist after adding some of the downcall infrastructure. Did a clean build and there were no warning associated with the 
> 
> Compiling up to 2 files for CLASSLIST_JAR
> Creating support/classlist.jar
> 
> steps.

This pull request has now been integrated.

Changeset: bccf057f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bccf057fa4a0208bda55d2972d0161044f050ea5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8355971: Build warnings after the changes for JDK-8354996

Reviewed-by: shade, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/24970

From iveresov at openjdk.org  Wed Apr 30 20:56:32 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 20:56:32 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v6]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <iQkD9-cnuldqXrJ02BYrNoSQGAKJhHBXAErV2b9LzSI=.33f3aeda-44e8-495c-8158-c5af908b27b4@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Remove the proxy class counter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/4514d032..38a156f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=04-05

  Stats: 9 lines in 2 files changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Wed Apr 30 21:00:58 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 21:00:58 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v6]
In-Reply-To: <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <3JsetDO0CDSY3TVxn9pC7YfbNq8-BDZ2UwNo38qJuOc=.e5b30111-294e-45ba-a9aa-cf8d09e26d45@github.com>
Message-ID: <lsK38eey4q0yiic0bJ86upCQKomdYpH4U5pK3EkXd5I=.6010fd6c-b7af-4482-b672-54533d1c2220@github.com>

On Sat, 26 Apr 2025 22:36:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the proxy class counter
>
> src/hotspot/share/cds/archiveBuilder.cpp line 770:
> 
>> 768:   relocate_embedded_pointers(&_rw_src_objs);
>> 769:   relocate_embedded_pointers(&_ro_src_objs);
>> 770:   log_info(cds)("Relocating %zu pointers, %zu tagged, %zu nulled",
> 
> `log_info(aot)` if it is Leyden related.

This more like a generic cds message. I'll leave this one as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2069431184

From iveresov at openjdk.org  Wed Apr 30 21:14:16 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 21:14:16 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v7]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <DG8t_ZSXe2aCHYonkRVjygGiV41eBMiLdBOpHe68jwo=.84d15ec6-bb5c-4bb6-9c55-2d8f2d929746@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Fix log tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/38a156f3..ef5dfcca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=05-06

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From iveresov at openjdk.org  Wed Apr 30 22:58:09 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 22:58:09 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v8]
In-Reply-To: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
Message-ID: <awCM4CJ_JEoOiuymWcTJDJWYrmGze05LgUHRk9F7cR0=.e27464dc-c5cd-4ba1-80e4-7caaf885cd37@github.com>

> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
> 
> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147

Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:

  Fix flag behavior

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24886/files
  - new: https://git.openjdk.org/jdk/pull/24886/files/ef5dfcca..b937681e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886

PR: https://git.openjdk.org/jdk/pull/24886

From vlivanov at openjdk.org  Wed Apr 30 23:04:52 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 23:04:52 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <lKhMKH6GAr5VTJ14lnXfdlZFbSlPnnxGBVRBbHCWmno=.7c59eeeb-1142-4bec-88c4-0128a7d320e9@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
 <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>
 <sAj_5Nc4IQF_zqXtKB38KvFGQmeKtrlwpb9Ag7TdpuE=.596532a6-cd43-472c-a094-77cdabbf0ae6@github.com>
 <2q_jgLrJim5ntOfr3awHdl1HTgrWtcTdcHWsO_CfnHU=.7958f1ef-9792-416a-9474-33f776e01fb5@github.com>
 <lKhMKH6GAr5VTJ14lnXfdlZFbSlPnnxGBVRBbHCWmno=.7c59eeeb-1142-4bec-88c4-0128a7d320e9@github.com>
Message-ID: <IpPvTf7clAVDi6c-vstNTm_caiWCk0b8omA6gOpXRks=.864736fe-b7a3-4137-9ba5-0ab78070adcb@github.com>

On Wed, 30 Apr 2025 22:55:38 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I added `log_info()` to `exit_vm_on_*_failure()` methods to produce notification when AbortVMOnAOTCodeFailure flag is off (default value).
>
> The naming (`exit_vm_on_load_failure` and  `exit_vm_on_store_failure`) still look confusing to me. By default, they disable `AOTAdapterCaching` and issue a message, but the name strongly suggests that execution halts there:
> 
> if (!open_cache(is_dumping, is_using)) {
>     if (is_using) {
>       exit_vm_on_load_failure();
>     } else {
>       exit_vm_on_store_failure();
>     }
>     return;
>   }

> Setting AOTAdapterCaching to false on failure is simple indication that adapter caching is switched off for someone who will look on final state of flag.

But how does it affect execution? What's the intended behavior when a failure happens during store attempt? What are the consistency guarantees for AOT code cache during dumping in presense of store failures? What I see right now is that errors reported by `AOTCodeCache::store_code_blob()` are silently ignored. How does `_cache` notice a store failure during dumping phase?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069625888

From vlivanov at openjdk.org  Wed Apr 30 23:04:51 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 23:04:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v7]
In-Reply-To: <2q_jgLrJim5ntOfr3awHdl1HTgrWtcTdcHWsO_CfnHU=.7958f1ef-9792-416a-9474-33f776e01fb5@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <O7cCWyvSGJvIfBTk-TuYf5uZDmboXEqERnk2WgcN33w=.ccbff04d-013a-4641-9f84-c6bb87f55d8d@github.com>
 <orOIyqYC--jOvySA0T5RjctHNp-agp3lmcDpwZl__4k=.ce021d43-3457-486c-8363-c174034813d3@github.com>
 <XE4WHeKlBMxpO0QdfJtS-BVq-iKo2mR9aEgHfOrabeo=.6a738813-cfd5-49bd-8c09-e15dc30599f9@github.com>
 <sAj_5Nc4IQF_zqXtKB38KvFGQmeKtrlwpb9Ag7TdpuE=.596532a6-cd43-472c-a094-77cdabbf0ae6@github.com>
 <2q_jgLrJim5ntOfr3awHdl1HTgrWtcTdcHWsO_CfnHU=.7958f1ef-9792-416a-9474-33f776e01fb5@github.com>
Message-ID: <lKhMKH6GAr5VTJ14lnXfdlZFbSlPnnxGBVRBbHCWmno=.7c59eeeb-1142-4bec-88c4-0128a7d320e9@github.com>

On Fri, 25 Apr 2025 00:52:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> AOT adapters code caching and loading is guarded by these methods not by flag.
>> 
>> Setting AOTAdapterCaching to false on failure is simple indication that adapter caching is switched off for someone who will look on final state of flag.
>
> I added `log_info()` to `exit_vm_on_*_failure()` methods to produce notification when AbortVMOnAOTCodeFailure flag is off (default value).

The naming (`exit_vm_on_load_failure` and  `exit_vm_on_store_failure`) still look confusing to me. By default, they disable `AOTAdapterCaching` and issue a message, but the name strongly suggests that execution halts there:

if (!open_cache(is_dumping, is_using)) {
    if (is_using) {
      exit_vm_on_load_failure();
    } else {
      exit_vm_on_store_failure();
    }
    return;
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069613390

From iveresov at openjdk.org  Wed Apr 30 23:00:50 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 30 Apr 2025 23:00:50 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v4]
In-Reply-To: <sxJezTFWs3ipwJWrWvlasO4UtDyFsekLKbbVXn9wiSc=.ac69946c-9563-4f07-bcd0-ea701b5213f5@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <SwKeFzdiq_dckyMQdUm895yytI5abKcRHd0c7YxGdaw=.7b844779-52fe-4ea7-b28d-23cfb3f9fb51@github.com>
 <sxJezTFWs3ipwJWrWvlasO4UtDyFsekLKbbVXn9wiSc=.ac69946c-9563-4f07-bcd0-ea701b5213f5@github.com>
Message-ID: <h-ued-NooDmItywARFEokHqTj7YVJ5kO6tpObLy5b74=.3a018b59-77a7-4574-ba5c-dc1730737bee@github.com>

On Mon, 28 Apr 2025 17:35:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
>> 
>>  - Merge branch 'master' into pp2
>>  - Fix class filtering
>>  - Remove the workaround of setting AOTRecordTraining during assembly
>>  - Address some of the review comments
>>  - Merge branch 'master' into pp
>>  - Add AOTCompileEagerly flag to control compilation after clinit
>>  - Port 8355334: [leyden] Missing type profile info in archived training data
>>  - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation
>>  - Use ENABLE_IF macro
>>  - Missing part of the last commit
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/2447b981...7fb7ae62
>
> Looks better.
> There are still places where UL is used specifically for TD processing. Consider using `(aot, training)` there instead of `(cds)`.

Vladimir (@vnkozlov), I did the changes that you requested. You please do another pass? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24886#issuecomment-2843621301

From vlivanov at openjdk.org  Wed Apr 30 23:04:51 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 30 Apr 2025 23:04:51 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v12]
In-Reply-To: <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
Message-ID: <nNxodW9we47Xlgm4QDloanOd3UjxnwyfT5uUuxEnN0U=.d34cc942-9260-4d3e-8c77-0aeb0f9e3f86@github.com>

On Wed, 30 Apr 2025 02:05:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class information in AOT cache which helps Java startup performance.
>> 
>> We should also preserve adapters (i2c, c2i) to further improve performance of class linking where adapters are generated.
>> 
>> Short running Java application can see several percents improvement. I got 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>> 
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0299401 +- 0.0000504 seconds time elapsed  ( +-  0.17% )
>> 
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed
>>          0.0318654 +- 0.0000535 seconds time elapsed  ( +-  0.17% )
>> 
>> 
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to unlock them):
>> 
>> 
>> -XX:+AOTAdapterCaching  - Enable or disable saving and restoring i2c2i adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code caching failure
>> 
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>> 
>> To use AOT adapters follow process described in JEP 483:
>> 
>> 
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>> 
>> 
>> There are several new UL flag combinations to trace the AOT code caching process:
>> 
>> 
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>> 
>> 
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>> 
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address Ioi's comments

src/hotspot/share/code/aotCodeCache.cpp line 60:

> 58:     vm_exit_during_initialization("Unable to use AOT Code Cache.", nullptr);
> 59:   }
> 60:   log_info(aot, codecache, init)("Unable to use AOT Code Cache.");

Should it be a warning instead?

src/hotspot/share/code/aotCodeCache.cpp line 69:

> 67:     vm_abort(false);
> 68:   }
> 69:   log_info(aot, codecache, exit)("Unable to create AOT Code Cache.");

Same here (`log_warning`?).

src/hotspot/share/code/aotCodeCache.hpp line 31:

> 29:  * AOT Code Cache collects code from Code Cache and corresponding metadata
> 30:  * during application training run.
> 31:  * In following "production" runs this code and data can me loaded into

s/me/be/

src/hotspot/share/code/codeBlob.hpp line 208:

> 206:   CodeBlob* as_codeblob() const               { return (CodeBlob*) this; }
> 207:   AdapterBlob* as_adapter_blob() const        { assert(is_adapter_blob(), "must be adapter blob"); return (AdapterBlob*) this; }
> 208:   ExceptionBlob* as_exception_blob() const    { assert(is_exception_stub(), "must be exception stub"); return (ExceptionBlob*) this; }

`ExceptionBlob` is C2-specific, but `as_exception_blob()` is unused.

src/hotspot/share/code/relocInfo.hpp line 1292:

> 1290:   void pack_data_to(CodeSection * dest) override;
> 1291:   void unpack_data() override;
> 1292: #if defined(AARCH64)

It's unfortunate to see AArch64-specific code in shared code. 

But I don't see anything besides`pd_destination()` and `pd_set_destination()` declarations. Where're their bodies?

src/hotspot/share/runtime/sharedRuntime.cpp line 2780:

> 2778: 
> 2779: #ifndef PRODUCT
> 2780: void AdapterHandlerLibrary::print_adapter_handler_info(AdapterHandlerEntry* handler, AdapterBlob* adapter_blob) {

Suggestion: pass `tty` explicitly as `outputStream*`


void AdapterHandlerLibrary::print_adapter_handler_info_on(outptutStream* st, AdapterHandlerEntry* handler, AdapterBlob* adapter_blob) {

src/hotspot/share/runtime/sharedRuntime.cpp line 2852:

> 2850:     entry_offset[2] = handler->get_c2i_unverified_entry() - i2c_entry;
> 2851:     entry_offset[3] = handler->get_c2i_no_clinit_check_entry() - i2c_entry;
> 2852:     AOTCodeCache::store_code_blob(*adapter_blob, AOTCodeEntry::Adapter, id, name, AdapterHandlerEntry::ENTRIES_COUNT, entry_offset);

What the intended behavior here when `AOTCodeCache::store_code_blob` fails?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069610692
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069611080
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069563790
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069585108
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069558227
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069547808
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069619002

From kvn at openjdk.org  Wed Apr 30 23:40:47 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Apr 2025 23:40:47 GMT
Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v8]
In-Reply-To: <awCM4CJ_JEoOiuymWcTJDJWYrmGze05LgUHRk9F7cR0=.e27464dc-c5cd-4ba1-80e4-7caaf885cd37@github.com>
References: <pK0toJwLcBqugQTkuJRdQkj0CHes3oWUWitd0U-yGPE=.a5aecb5c-8fe1-4766-b62f-8fc606925e8e@github.com>
 <awCM4CJ_JEoOiuymWcTJDJWYrmGze05LgUHRk9F7cR0=.e27464dc-c5cd-4ba1-80e4-7caaf885cd37@github.com>
Message-ID: <MCF4dHEurV2K-P01yMpAWEFnmWfLjzQnzscXTWrw3Z8=.b0ac4201-8b08-4c2e-87cc-2be9f64038ab@github.com>

On Wed, 30 Apr 2025 22:58:09 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs.
>> 
>> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147
>
> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix flag behavior

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2808829130

From kvn at openjdk.org  Wed Apr 30 23:58:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Apr 2025 23:58:48 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v12]
In-Reply-To: <nNxodW9we47Xlgm4QDloanOd3UjxnwyfT5uUuxEnN0U=.d34cc942-9260-4d3e-8c77-0aeb0f9e3f86@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
 <nNxodW9we47Xlgm4QDloanOd3UjxnwyfT5uUuxEnN0U=.d34cc942-9260-4d3e-8c77-0aeb0f9e3f86@github.com>
Message-ID: <4sPSeelY_aPOk87j8XiobBz2MjWX1nzBeHWlhgFHnDs=.c498d25f-acbf-493f-9eaa-0fa2ea43433f@github.com>

On Wed, 30 Apr 2025 22:22:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Ioi's comments
>
> src/hotspot/share/code/relocInfo.hpp line 1292:
> 
>> 1290:   void pack_data_to(CodeSection * dest) override;
>> 1291:   void unpack_data() override;
>> 1292: #if defined(AARCH64)
> 
> It's unfortunate to see AArch64-specific code in shared code. 
> 
> But I don't see anything besides`pd_destination()` and `pd_set_destination()` declarations. Where're their bodies?

Good catch. I copied it from leyden/premain but it is used only for trampoline jump relocation for calls in nmethods on Aarch64. They are not present in adapters. I remove this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069677599

From kvn at openjdk.org  Wed Apr 30 23:55:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Apr 2025 23:55:48 GMT
Subject: RFR: 8350209: Preserve adapters in AOT cache [v12]
In-Reply-To: <nNxodW9we47Xlgm4QDloanOd3UjxnwyfT5uUuxEnN0U=.d34cc942-9260-4d3e-8c77-0aeb0f9e3f86@github.com>
References: <iVyvqzbLDDxEcEcSJS7P6ULuZBXpkvSCC717CVrQpvQ=.f12f91a7-cd3a-4ae6-b622-e7cf1e9cc3bc@github.com>
 <ucFfHqtHhOl_HoumjQ0QnRbEDLlDwniKGIVmAbO6DuU=.e2283c61-112a-47b6-8c41-f82b415143d9@github.com>
 <nNxodW9we47Xlgm4QDloanOd3UjxnwyfT5uUuxEnN0U=.d34cc942-9260-4d3e-8c77-0aeb0f9e3f86@github.com>
Message-ID: <TDyZK1gyIIR3B8pTzWhmALZb2QSmjLjUvN6N37KvVCI=.86298dd2-a1d8-4ed4-b3a2-ac90cc0a161b@github.com>

On Wed, 30 Apr 2025 22:09:24 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Ioi's comments
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2780:
> 
>> 2778: 
>> 2779: #ifndef PRODUCT
>> 2780: void AdapterHandlerLibrary::print_adapter_handler_info(AdapterHandlerEntry* handler, AdapterBlob* adapter_blob) {
> 
> Suggestion: pass `tty` explicitly as `outputStream*`
> 
> 
> void AdapterHandlerLibrary::print_adapter_handler_info_on(outptutStream* st, AdapterHandlerEntry* handler, AdapterBlob* adapter_blob) {

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069675872