From dnsimon at openjdk.org  Sat Feb  1 07:21:52 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 1 Feb 2025 07:21:52 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
Message-ID: <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>

On Fri, 31 Jan 2025 13:56:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
> 
> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
> 
> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
> 
> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.

A lot of these rules looks like they could be checked with some simple scripting or additions to jcheck. Have you considered that?

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

PR Comment: https://git.openjdk.org/jdk/pull/23388#issuecomment-2628824819

From stefank at openjdk.org  Mon Feb  3 12:14:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 3 Feb 2025 12:14:35 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
Message-ID: <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>

> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
> 
> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
> 
> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
> 
> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.

Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:

 - Update hotspot-style.md
 - Update hotspot-style.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23388/files
  - new: https://git.openjdk.org/jdk/pull/23388/files/51913afa..f01c564c

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

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

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

From stefank at openjdk.org  Mon Feb  3 12:14:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 3 Feb 2025 12:14:36 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>
Message-ID: <eF88iMTl6J-Wl5Sygf3UqVKE9EzAo1TehF6-boPrdfM=.88524e99-395c-43dd-8256-1abacabb3f58@github.com>

On Sat, 1 Feb 2025 07:19:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> A lot of these rules looks like they could be checked with some simple scripting or additions to jcheck. Have you considered that?

I haven't felt the urge to write such a script, but I know that others have scripts to sort the includes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23388#issuecomment-2630774637

From dnsimon at openjdk.org  Mon Feb  3 12:17:50 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 3 Feb 2025 12:17:50 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <eF88iMTl6J-Wl5Sygf3UqVKE9EzAo1TehF6-boPrdfM=.88524e99-395c-43dd-8256-1abacabb3f58@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>
 <eF88iMTl6J-Wl5Sygf3UqVKE9EzAo1TehF6-boPrdfM=.88524e99-395c-43dd-8256-1abacabb3f58@github.com>
Message-ID: <1gOEDAkU1eGcUnYqPawR3g5OqAseBiVIVPUIi4O9GYc=.321e1b86-3c6f-4c92-8036-27240a778659@github.com>

On Mon, 3 Feb 2025 12:11:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I haven't felt the urge to write such a script, but I know that others have scripts to sort the includes

Ok, it was just a suggestion. My experience is that while clearly written conventions/rules are important, the more they can be automated, the less hassle for everyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/23388#issuecomment-2630781761

From mbaesken at openjdk.org  Mon Feb  3 12:23:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Feb 2025 12:23:49 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <SLSw-asFoNyGesCI63lYE1XcMnKt6eB_bgDW2mveUoA=.846a0afa-71d6-40c0-9d6b-850d76ac667b@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
 <kbMpDioYGnmsYKvujapuNaKSeCfNhDYKzIcWG0FLovI=.63dc7220-d014-4834-bc61-bd321e6e7834@github.com>
 <fTozCe7sL7M4H2Gs_6ytw37tp5MTE4KB2Qcm3ISkk-Q=.00bfb0e2-9e09-41c8-a845-99e9e0559921@github.com>
 <SLSw-asFoNyGesCI63lYE1XcMnKt6eB_bgDW2mveUoA=.846a0afa-71d6-40c0-9d6b-850d76ac667b@github.com>
Message-ID: <MC86x_UCd_0Jok5ac7p5W4HIOZo4j6q7a_ku-RJ27EE=.8694284a-86eb-4d1b-9c95-92f0a0a52df4@github.com>

On Fri, 31 Jan 2025 13:59:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best 
> thing to do after some more testing.

The size optimization worked pretty well on most platforms , have to look still more into the compilation times of the this lib for a complete picture. No jtreg/jck failures seen.
These are the sizes when comparing LOW to SIZE optimization
Linux ppc64le   500K -> 376K
Linux x86_64    364k -> 304 K
macOS aarch64  468K -> 404K
AIX   2.5M  -> 2.1M
The debuginfo files get smaller too by ~ 10 - 20 %  (AIX has no separate debuginfo file that's why the large binary)

However for MSVC the SIZE optimization flags seem to be bad , the binaries get *LARGER* not smaller !   I opened  https://bugs.openjdk.org/browse/JDK-8349214 .

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2630793171

From mbaesken at openjdk.org  Mon Feb  3 12:29:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Feb 2025 12:29:33 GMT
Subject: RFR: 8349150: Support precompiled headers on AIX
Message-ID: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>

The clang compiler currently used on AIX should be able to support precompiled headers in the HS build (same as on Linux or macOS where clang is used).
However currently the precompiled headers feature is disabled on AIX (probably because the old xlc had issues with this feature).

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

Commit messages:
 - JDK-8349150

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

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

From jkern at openjdk.org  Mon Feb  3 12:41:45 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 3 Feb 2025 12:41:45 GMT
Subject: RFR: 8349150: Support precompiled headers on AIX
In-Reply-To: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
References: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
Message-ID: <qsZMQiKw9RATy3X3IuuqCOXBMsNs8ATkjenc3166gbI=.daaf34b1-065b-4460-8ffa-bf1aa0f9ea4e@github.com>

On Mon, 3 Feb 2025 12:24:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The clang compiler currently used on AIX should be able to support precompiled headers in the HS build (same as on Linux or macOS where clang is used).
> However currently the precompiled headers feature is disabled on AIX (probably because the old xlc had issues with this feature).

LGTM

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23417#pullrequestreview-2589775189

From erikj at openjdk.org  Mon Feb  3 17:29:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Feb 2025 17:29:46 GMT
Subject: RFR: 8348190: Framework for tracing makefile inclusion and parsing
In-Reply-To: <aVZWSShwSSRuV7dA6Y-rd9LpHIwlHMklJ3suQkfQK9c=.f1785f9b-7459-487f-a457-a5c1557ff94b@github.com>
References: <aVZWSShwSSRuV7dA6Y-rd9LpHIwlHMklJ3suQkfQK9c=.f1785f9b-7459-487f-a457-a5c1557ff94b@github.com>
Message-ID: <t0IJTe0UU1U5OT7cSmP7CnUi8ipxy3o8MvIH_RPw5R4=.0106de23-ad20-4949-988d-4b1c8c241089@github.com>

On Fri, 31 Jan 2025 17:45:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A major problem when debugging the build system is figuring out what makefiles are evaluated, and in which order. 
> 
> Our makefiles comes in three flavors, which I have termed "files", "includes" and "snippets", for the purpose of being able to reason about them. The difference is this:
> * "files" (that is, "top-level files") are run directly by calling `make -f FooFile.gmk`
> * "includes" are included by other makesfiles using `include FooInclude.gmk`
> * "snippets" are automatically included by the framework, based on special naming rules
> 
> This patch adds a systematic structure to files, includes and snippets, which allows for a logging framework to be attached.
> 
> The log will look something like this:
> 
> 
> :Enter Main.gmk
> :    Enter common/MakeBase.gmk [include]
> :         Enter common/Utils.gmk [include]
> :         Leave common/Utils.gmk
> :         Enter common/FileUtils.gmk [include]
> :         Leave common/FileUtils.gmk
> :    Leave common/MakeBase.gmk
> :    Enter MainSupport.gmk [include]
> :    Leave MainSupport.gmk
> :    Enter common/FindTests.gmk [include]
> :    Leave common/FindTests.gmk
> :    Enter common/Modules.gmk [include]
> :    Leave common/Modules.gmk
> :Leave Main.gmk [now executing rules]
> 
> 
> Furthermore, this patch achieves a secondary benefit, which is arguably just as important, and that is simplifying the boilerplate in makefiles. I am not saying that it offers strictly *less* boilerplate -- in some cases, it is actually more than what we have right now. But it does offer *systematic* boilerplate. You only have to include the proper start/end makefile and then you're good to go. These start/end files implements the best practices that have evolved over the year (like include guards for includes), and standards we employ in the JDK build system (like always starting with a `default: all` rule). It became painfully obvious when implementing this PR that our adherence to these best practices are sketchy, at best. From now on, it will not be possible to miss declaring best practice boilerplate, since it is all concentrated in a single set of files.
> 
> While updating all makefiles to use these new systematic start/end includes, I took the opportunity to clean up the style used and make it more consistent. So now all makefiles follows this pattern (as far as applicable):
> 
> include Make[File/Include]Start.gmk
> 
> ################################################################################
> # High-level description of this file (if present).
> #############################...

I think this looks good. I have most looked at the second commit.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23399#pullrequestreview-2590576476

From erikj at openjdk.org  Mon Feb  3 17:41:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Feb 2025 17:41:46 GMT
Subject: RFR: 8349150: Support precompiled headers on AIX
In-Reply-To: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
References: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
Message-ID: <F1m_dvSNJ2tcbzhaMpneeDRSV4Q3yyy7s1EZVKYd-6I=.4a8f7fb8-cfec-4425-aab1-057a6602cd42@github.com>

On Mon, 3 Feb 2025 12:24:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The clang compiler currently used on AIX should be able to support precompiled headers in the HS build (same as on Linux or macOS where clang is used).
> However currently the precompiled headers feature is disabled on AIX (probably because the old xlc had issues with this feature).

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23417#pullrequestreview-2590600615

From jiangli at openjdk.org  Tue Feb  4 01:16:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Feb 2025 01:16:14 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported
 on static JDK
Message-ID: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>

Please review runtime/jni/atExit/TestAtExit.java test change:

- Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
- Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
  - JNI_GetDefaultJavaVMInitArgs
  - JNI_GetCreatedJavaVMs
  - JNI_CreateJavaVM

On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.

For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 

TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

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

Commit messages:
 - Fix typo.
 - - Remove BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit and don't link with libjvm for libatExit.

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

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

From mbaesken at openjdk.org  Tue Feb  4 08:13:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 08:13:13 GMT
Subject: RFR: 8349150: Support precompiled headers on AIX
In-Reply-To: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
References: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
Message-ID: <F0-U-OJKY9IxDe3WEKqHi9Ncr0fnG6US7amDo-u-os0=.3041c2ec-f1a4-4b40-aaea-3f8646946d8e@github.com>

On Mon, 3 Feb 2025 12:24:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The clang compiler currently used on AIX should be able to support precompiled headers in the HS build (same as on Linux or macOS where clang is used).
> However currently the precompiled headers feature is disabled on AIX (probably because the old xlc had issues with this feature).

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23417#issuecomment-2633167537

From mbaesken at openjdk.org  Tue Feb  4 08:13:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 08:13:14 GMT
Subject: Integrated: 8349150: Support precompiled headers on AIX
In-Reply-To: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
References: <Uii-_C9Fmrj8FEJ4X-BJcDk79pBhdscS-X_wbLLPD20=.990594fc-2553-446e-afc1-698e4c216218@github.com>
Message-ID: <QLqBd3Prd2Oamnbm2CNWAnxO7bCXQTNOJQXPtSKaaOU=.5a6de568-67f1-4680-a1b0-08cb2586524d@github.com>

On Mon, 3 Feb 2025 12:24:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The clang compiler currently used on AIX should be able to support precompiled headers in the HS build (same as on Linux or macOS where clang is used).
> However currently the precompiled headers feature is disabled on AIX (probably because the old xlc had issues with this feature).

This pull request has now been integrated.

Changeset: beae8843
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/beae8843b9b2433af5e9fbe420b17e663cbdb960
Stats:     16 lines in 2 files changed: 7 ins; 6 del; 3 mod

8349150: Support precompiled headers on AIX

Reviewed-by: jkern, erikj

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

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

From mbaesken at openjdk.org  Tue Feb  4 08:58:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 08:58:58 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
Message-ID: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>

Looks like the binary size optimization flags are not ideal when compiling with MSVC.
On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.

For example jvm.dll (build with VS2022) with current -Os size optimization
20M images/jdk/bin/server/jvm.dll

with -O1 set for size optimization
13M images/jdk/bin/server/jvm.dll

See the doc from MSVC about "optimize for size"
https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
"The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
The Os option is only a part of the size minimization flag set :
/O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

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

Commit messages:
 - JDK-8349214

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

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

From djelinski at openjdk.org  Tue Feb  4 09:42:10 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 4 Feb 2025 09:42:10 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <PCwFnMN0jd3CADK4Lw-qlfLQZCyCmDjJIydSAinzDIE=.10b72911-e0cb-44ed-bc59-0c87289d8387@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

Makes sense.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23432#pullrequestreview-2592259083

From dholmes at openjdk.org  Tue Feb  4 10:45:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Feb 2025 10:45:09 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
Message-ID: <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com>

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

@jianglizhou  I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a _static_ JDK we have to rewrite the test to perform a _dynamic_ lookup!

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2633523332

From magnus.ihse.bursie at oracle.com  Tue Feb  4 10:46:02 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 4 Feb 2025 11:46:02 +0100
Subject: BREAKING CHANGE: IncludeCustomExtension behavior changes
Message-ID: <25cc2ea0-600a-4f7e-a2b0-45bd406c365d@oracle.com>

Some details on how the IncludeCustomExtension hook is called will 
change when JDK-8348190[1] is integrated. The PR is currently open for 
reviewing on GitHub[2].

The big benefit of this change is that now the hooks will be 
automatically generated, so it will be possible to add hooks to each and 
every makefile without having to make any changes in the open JDK source 
code. However, as a result of this, the hooks will always only appear 
strictly before or after a makefile. While many of the current hooks are 
positioned closed to the top or bottom of a file, not all are, and this 
might change the behavior enough to render a pre-existing hook broken 
and in need of fixing to keep working.

Furthermore, the names passed to IncludeCustomExtension have been 
standardized to always end in -pre or -post, which was often, but not 
always, the case before. Rename your hooks accordingly.

/Magnus

[1] https://bugs.openjdk.org/browse/JDK-8348190
[2] https://github.com/openjdk/jdk/pull/23399


From ihse at openjdk.org  Tue Feb  4 10:54:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Feb 2025 10:54:09 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <dKemrecAFOq07ErMJOowN-l2eWo-SFOfKunME8s0rFU=.af8c22af-90cd-4fd5-a967-23afd9ea94b5@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

What libraries are currently optimized for size on Windows, i.e. is affected by this change?

What testing have you performed to ensure no new compiler bugs show up? Changing optimization level introduces a risk of compiler-related bugs, similar to compiler upgrades. Note that this is not only about bugs in the compiler, but in our code where we use undefined behavior, which happily have worked out fine for one optimization level, but which results in bad code generated (correctly) by the compiler.

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2633543966

From stefank at openjdk.org  Tue Feb  4 12:34:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Feb 2025 12:34:11 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <1gOEDAkU1eGcUnYqPawR3g5OqAseBiVIVPUIi4O9GYc=.321e1b86-3c6f-4c92-8036-27240a778659@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>
 <eF88iMTl6J-Wl5Sygf3UqVKE9EzAo1TehF6-boPrdfM=.88524e99-395c-43dd-8256-1abacabb3f58@github.com>
 <1gOEDAkU1eGcUnYqPawR3g5OqAseBiVIVPUIi4O9GYc=.321e1b86-3c6f-4c92-8036-27240a778659@github.com>
Message-ID: <i_yNnXdVx-o4xJDPQHS4zXcEpz4_85IH4tT4YPUaGHs=.d45e461f-748f-408c-8e0f-f7ce2b45d89a@github.com>

On Mon, 3 Feb 2025 12:14:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I haven't felt the urge to write such a script, but I know that others have scripts to sort the includes
> 
> Ok, it was just a suggestion. My experience is that while clearly written conventions/rules are important, the more they can be automated, the less hassle for everyone.

I agree, that a script is beneficial. Do you know of anyone that would be willing to help out and write such script?

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

PR Comment: https://git.openjdk.org/jdk/pull/23388#issuecomment-2633768991

From djelinski at openjdk.org  Tue Feb  4 12:55:27 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 4 Feb 2025 12:55:27 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <o0g9ROgfCc5X4dnQGRWq3l4fwpzCRRVuJbhLPrtgTXc=.97419920-0a19-470f-a7a2-74543ab29aaf@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

No libraries are optimized for size by default.

Optimization for size is only used by hotspot, and only when `opt-size` feature is enabled; I think `opt-size` may be enabled in the `minimal` variant.

Optimization level `O1` is already used in many places, specifically in every place that uses `HIGH` or `LOW` optimization.

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2633821183

From mbaesken at openjdk.org  Tue Feb  4 13:28:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 13:28:11 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <o0g9ROgfCc5X4dnQGRWq3l4fwpzCRRVuJbhLPrtgTXc=.97419920-0a19-470f-a7a2-74543ab29aaf@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
 <o0g9ROgfCc5X4dnQGRWq3l4fwpzCRRVuJbhLPrtgTXc=.97419920-0a19-470f-a7a2-74543ab29aaf@github.com>
Message-ID: <gKn44vPAZIRGK271FzTR6kZgQLtTfr_jhXtQ-OeIzyk=.24bfaf34-881c-4c9c-b391-2dda308e4553@github.com>

On Tue, 4 Feb 2025 12:53:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> No libraries are optimized for size by default.

True, it is at the moment only for opt-size / jvm.dll .

In future I plan to create a PR for libsplashscreen  using SIZE optimization, but currently this would lead to a larger (!) lib with MSVC because of the bad -Os , this does not make sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2633917964

From jwaters at openjdk.org  Tue Feb  4 13:33:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Feb 2025 13:33:13 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <T6vfHh1U8r__-3X5mLJN4VdaOH8dZeuPe4NTBdQs6kE=.a229b4e2-7d70-4f35-8ec7-6e19aa2b75e1@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

splashscreen already uses LOW for its optimization flags though. Is the intent to change it to SIZE for all compilers?

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2633942714

From stuefe at openjdk.org  Tue Feb  4 14:08:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Feb 2025 14:08:10 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
Message-ID: <RBP8We_FEtRFYyRvkt9PJ7FTQErp0fH_CVCbjVGQabA=.9108fab2-a35c-4851-92dc-409723534355@github.com>

On Mon, 3 Feb 2025 12:14:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
>> 
>> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
>> 
>> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
>> 
>> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update hotspot-style.md
>  - Update hotspot-style.html

This looks good to me. Thank you.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23388#pullrequestreview-2592970726

From mbaesken at openjdk.org  Tue Feb  4 14:23:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 14:23:09 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <T6vfHh1U8r__-3X5mLJN4VdaOH8dZeuPe4NTBdQs6kE=.a229b4e2-7d70-4f35-8ec7-6e19aa2b75e1@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
 <T6vfHh1U8r__-3X5mLJN4VdaOH8dZeuPe4NTBdQs6kE=.a229b4e2-7d70-4f35-8ec7-6e19aa2b75e1@github.com>
Message-ID: <zj3nJp2tG9gPd-_GLiB01keQnvAMvg_4KKTvL2wgbD8=.37ad6e3f-c20a-4835-89c5-b4fc7f3bc261@github.com>

On Tue, 4 Feb 2025 13:30:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> splashscreen already uses LOW for its optimization flags though. Is the intent to change it to SIZE for all compilers?

LOW uses NORM and this is already O1  
`C_O_FLAG_NORM="-O1"`

so for Windows switching to SIZE won't change anything after this PR.  So yes it will probably SIZE for splashscreen  for all compilers.

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2634109704

From mbaesken at openjdk.org  Tue Feb  4 15:40:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 15:40:25 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after recent
 PCH changes
Message-ID: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>

When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :


cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]

+ exit 1
gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1


Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196

Same issue can be observed on Windows x86_64 (VS2022 used).

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

Commit messages:
 - JDK-8349140

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

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

From jwaters at openjdk.org  Tue Feb  4 15:50:11 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Feb 2025 15:50:11 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

make/hotspot/lib/JvmOverrideFiles.gmk line 154:

> 152: else ifeq ($(call isTargetOs, windows), true)
> 153:   JVM_PRECOMPILED_HEADER_EXCLUDE := \
> 154:       bytecodeInterpreter.cpp \

Does bytecodeInterpreter.cpp and friend no longer need to be excluded from precompiled headers? Windows/Zero might not exist yet, but I don't think we'd want to preclude that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1941430884

From mbaesken at openjdk.org  Tue Feb  4 16:04:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 16:04:12 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
Message-ID: <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>

On Tue, 4 Feb 2025 15:47:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
>> 
>> 
>> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
>> 
>> + exit 1
>> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
>> 
>> 
>> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
>> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
>> 
>> Same issue can be observed on Windows x86_64 (VS2022 used).
>
> make/hotspot/lib/JvmOverrideFiles.gmk line 154:
> 
>> 152: else ifeq ($(call isTargetOs, windows), true)
>> 153:   JVM_PRECOMPILED_HEADER_EXCLUDE := \
>> 154:       bytecodeInterpreter.cpp \
> 
> Does bytecodeInterpreter.cpp and friend no longer need to be excluded from precompiled headers? Windows/Zero might not exist yet, but I don't think we'd want to preclude that

I cannot find a bytecodeInterpreterWithChecks.cpp  , where is this located ?  Regarding bytecodeInterpreter.cpp I see no differences in opt setting, so far I don't know why this one should be excluded .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1941456137

From jwaters at openjdk.org  Tue Feb  4 16:24:18 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Feb 2025 16:24:18 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <uc2DLsk_K7QkD6vGiLx4ZFrTydAJmvcWilC7oEB0IDY=.7802146a-46e9-49c7-a837-86addbfe142c@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23442#pullrequestreview-2593398769

From jwaters at openjdk.org  Tue Feb  4 16:24:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Feb 2025 16:24:19 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
Message-ID: <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>

On Tue, 4 Feb 2025 16:01:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/hotspot/lib/JvmOverrideFiles.gmk line 154:
>> 
>>> 152: else ifeq ($(call isTargetOs, windows), true)
>>> 153:   JVM_PRECOMPILED_HEADER_EXCLUDE := \
>>> 154:       bytecodeInterpreter.cpp \
>> 
>> Does bytecodeInterpreter.cpp and friend no longer need to be excluded from precompiled headers? Windows/Zero might not exist yet, but I don't think we'd want to preclude that
>
> I cannot find a bytecodeInterpreterWithChecks.cpp  , where is this located ?  Regarding bytecodeInterpreter.cpp I see no differences in opt setting, so far I don't know why this one should be excluded .

On closer inspection bytecodeInterpreterWithChecks.cpp might be a remnant of the old Interpreter that no longer exists. Alright, this should be ok then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1941496260

From mdoerr at openjdk.org  Tue Feb  4 16:32:11 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Feb 2025 16:32:11 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
 <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
Message-ID: <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>

On Tue, 4 Feb 2025 16:21:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I cannot find a bytecodeInterpreterWithChecks.cpp  , where is this located ?  Regarding bytecodeInterpreter.cpp I see no differences in opt setting, so far I don't know why this one should be excluded .
>
> On closer inspection bytecodeInterpreterWithChecks.cpp might be a remnant of the old Interpreter that no longer exists. Alright, this should be ok then

I think bytecodeInterpreterWithChecks was removed a long time ago. It is still referenced in 8u-dev: https://github.com/openjdk/jdk8u-dev/blob/master/hotspot/src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
I guess that both interpreter excludes could be removed from `JVM_PRECOMPILED_HEADER_EXCLUDE`. @coleenp may know more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1941511445

From jiangli at openjdk.org  Tue Feb  4 16:53:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Feb 2025 16:53:10 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <8uTxxUpewnnq9r9R_1ff8zLpqFOk9F1J8m69FZPPZh4=.1efa460b-746a-401b-b440-e145d334e966@github.com>
Message-ID: <2Nds-2Yjm3OCM766NqCT2jUCMuP7p0FbRQXSRtS9e6Y=.66a07400-9597-4609-bb06-88b43d402468@github.com>

On Tue, 4 Feb 2025 10:42:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a _static_ JDK we have to rewrite the test to perform a _dynamic_ lookup!

@dholmes-ora Thanks for the forthright response. JNI functions are already dynamically called. E.g. in the same test here:


    res = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);


We don't need to change those at all to work on static-jdk. The existing design of JNI functions can work on both dynamic JDK and static JDK. 

The calls fixed by this PR are the very few exceptions that do not follow the design principle. I do think we should fix them by following the right patterns/conventions. Note `LoadJavaVM` in JDK code (https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.base/unix/native/libjli/java_md.c#L524C1-L524C11) calls these functions 'properly', see
https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.base/unix/native/libjli/java_md.c#L548.

So far I've only found this test in hotspot tier1 and libExplicitAttach (AttachTest_id0) in JDK tier1 with the issue.

@dholmes-ora If we don't go this change, do you have any other suggestion? One other possible alternative that I can think is using weak symbols, however I think that's no better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634531490

From jiangli at openjdk.org  Tue Feb  4 17:20:12 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Feb 2025 17:20:12 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
Message-ID: <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634595988

From erikj at openjdk.org  Tue Feb  4 17:34:21 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Feb 2025 17:34:21 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <2uoKUCvzzcMuBAAzaBN2UIUYANLjkGU-ev1sFohoIgY=.d1302e74-b775-44d7-b36e-161a8b19bff0@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23442#pullrequestreview-2593573144

From alanb at openjdk.org  Tue Feb  4 19:07:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 19:07:16 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
Message-ID: <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>

On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review runtime/jni/atExit/TestAtExit.java test change:
>> 
>> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
>> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>>   - JNI_GetDefaultJavaVMInitArgs
>>   - JNI_GetCreatedJavaVMs
>>   - JNI_CreateJavaVM
>> 
>> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
>> 
>> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
>> 
>> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.
>
> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.

> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup!

A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM).

So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634824084

From jiangli at openjdk.org  Tue Feb  4 19:45:20 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Feb 2025 19:45:20 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>
Message-ID: <wi7ODbH8AG44qm4dFuQYIsUnUqngALcxcx6ulcRq6A8=.f201cd96-7d56-4c2c-a907-feceb20dc628@github.com>

On Tue, 4 Feb 2025 19:04:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A static build isn't really suitable for custom launchers (or anything that embeds a VM).

Just want to provide some relevant data point. We build custom launcher and statically link with the libjvm (for hermetic case). If libjvm is statically linked with the launcher, then there's actually no need to change the direct calls to those JNI_ functions. The direct calls are not problematic on static build. 

> An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. 

The alternative also sounds reasonable to me. We could skip running on static JDK if a test explicitly requires libjvm.so, libjava.so, etc at runtime, at least initially.

> At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.

That's a good point. We can add a `vm.static.jdk` to help test selection.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2634906630

From ihse at openjdk.org  Tue Feb  4 21:06:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Feb 2025 21:06:16 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <a0d-uvgShpI6zXUK5a47XDIoqXNiraUA-7buChYt1ng=.9d591ef8-e0d0-4f54-87b0-569311948b79@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

Marked as reviewed by ihse (Reviewer).

Sounds good then. 

The optimization levels were kind of a mess that we "inherited" from the old build system, were they had just agglutinated over the years, probably dating back to Java 1.0, with nobody left around to remember why they were the way they were.

So it is definitely ripe for an overhaul. Anything you can do in this area is much appreciated, as long as it does not cause any regressions.

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

PR Review: https://git.openjdk.org/jdk/pull/23432#pullrequestreview-2594062927
PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2635070522

From jianglizhou at google.com  Tue Feb  4 22:30:29 2025
From: jianglizhou at google.com (Jiangli Zhou)
Date: Tue, 4 Feb 2025 14:30:29 -0800
Subject: Add static-jdk build in GHA
Message-ID: <CALrW1jz9npybbioiL8Gki6Uae56wKMxTgu-z-oqHSpqCwi0LMA@mail.gmail.com>

With the current state of JDK mainline for static JDK support, it's a good
time to add 'static-jdk' build as a minimum/initial pre-integration check
in GHA. It helps catch regressions accidentally introduced in any new
changes that could break the static JDK build (e.g. duplicate symbols in
different JDK native libraries). We have also discussed this topic during
the on-going hermetic Java zoom meetings with Ron, Alan, Magnus and others.
As a starting point, we can add release and fastdebug static-jdk builds on
linux-x64 for now, and then expand to other platforms when appropriate.

Here are some measurements that I collected from building jdk-image and
static-jdk-image for release and fastdebug binaries on my local linux x64
machine (with gcc as the default). For release build, building jdk-image
and static-jdk-image takes about the same real time. For fastdebug,
building a static-jdk-image takes ~1m more than building a jdk-image on my
linux machine. Thoughts and additional suggestions are welcome!

Clean builds
==========

jdk-image:
----------------
release: real 2m20.327s
fastdebug: real 3m0.262s

static-jdk-image:
----------------------
release: real 2m51.024s
fastdebug: real 4m11.928s

Best,
Jiangli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250204/df2c9e9b/attachment-0001.htm>

From dholmes at openjdk.org  Wed Feb  5 01:12:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 01:12:31 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <wi7ODbH8AG44qm4dFuQYIsUnUqngALcxcx6ulcRq6A8=.f201cd96-7d56-4c2c-a907-feceb20dc628@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>
 <wi7ODbH8AG44qm4dFuQYIsUnUqngALcxcx6ulcRq6A8=.f201cd96-7d56-4c2c-a907-feceb20dc628@github.com>
Message-ID: <XdiWizPhzjZKxUVjTC2pw9QzVk5ye9et8-WwcZdDzeQ=.97034285-e91a-44f7-b4bb-46aefc297ff2@github.com>

On Tue, 4 Feb 2025 19:42:42 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup!
>> 
>> A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM).
>> 
>> So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.
>
>> A static build isn't really suitable for custom launchers (or anything that embeds a VM).
> 
> Just want to provide some relevant data point. We build custom launcher and statically link with the libjvm (for hermetic case). If libjvm is statically linked with the launcher, then there's actually no need to change the direct calls to those JNI_ functions. The direct calls are not problematic on static build. 
> 
>> An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. 
> 
> The alternative also sounds reasonable to me. We could skip running on static JDK if a test explicitly requires libjvm.so, libjava.so, etc at runtime, at least initially.
> 
>> At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.
> 
> That's a good point. We can add a `vm.static.jdk` to help test selection.

Thanks for clarifying @jianglizhou . Okay so the issue is only with the top-level invocation API functions:
 - JNI_GetDefaultJavaVMInitArgs
 - JNI_GetCreatedJavaVMs
 - JNI_CreateJavaVM
and as noted launchers have the choice of either linking with libjvm.so or else using dynamic lookup. The former doesn't work with a static JDK (can we link with libjvm.a?). So in the context of fixing a couple of tests this is okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635480736

From dholmes at openjdk.org  Wed Feb  5 01:15:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 01:15:29 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
Message-ID: <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>

On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.

Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635483683

From dholmes at openjdk.org  Wed Feb  5 01:48:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 01:48:23 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
Message-ID: <mcpqhke7f3Jhgu0oQMvjkL1C0cQYGmK4UtnksEmX0X0=.7b9aca6e-2665-4967-91b4-e5cd40731a13@github.com>

On Mon, 3 Feb 2025 12:14:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
>> 
>> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
>> 
>> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
>> 
>> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update hotspot-style.md
>  - Update hotspot-style.html

Generally seems fine. Thanks.

doc/hotspot-style.html line 213:

> 211: <li><p>Put conditional inclusions (`#if ...`) at the end of the section of HotSpot
> 212: include lines. This also applies to macro-expanded includes of platform
> 213: dependent files.</p></li>

What is the order for the conditional sections? Alphabetic on the include guard?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23388#pullrequestreview-2594441092
PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1942135021

From jiangli at openjdk.org  Wed Feb  5 03:07:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 5 Feb 2025 03:07:14 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
Message-ID: <Yxf_A2OW5cAXThTfBk_6r2UUQcOOt0z1Om4X_6Vv5VQ=.6d97600e-04a4-4a30-89d6-199eb904aa72@github.com>

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

I want to answer the question carefully to avoid possible confusions, so the comment below may provide extra information (also verbose) than just addressing the question. Please let me know if anything is unclear.

>   and as noted launchers have the choice of either linking with libjvm.so or else using dynamic lookup. The former doesn't work with a static JDK (can we link with libjvm.a?). 

Yes. A launcher executable can explicitly link with a native library, either using .so (shared library)  or .a (static library) if the launcher code has any direct references to symbols defined in the native library. The launcher can also choose to do dynamic symbol lookup and avoids the need for explicitly linking with the native library. 

If a launcher executable is linked with libjvm.so at build time, it requires libjvm.so to be resolved (normally from the RPATH) and loaded successfully when the launcher executable is loaded. Otherwise the executable fails to load and start due to the missing libjvm.so dependency. If a launcher executable is statically linked with libjvm.a, runtime does not try to find the libjvm.a since that is already built into the executable.

Same for a shared library (e.g. the libatExit.so used by the test) linked with libjvm.so, the shared library fails to be loaded if libjvm.so do not present at runtime.  

If launcher code choose to use dynamic symbol lookup and avoids linking with libjvm.so, the launcher code can support both dynamic case and static case. The `java` launcher does that.

> So in the context of fixing a couple of tests this is okay.

Yeah, since there are just few cases in the tests, I feel fixing these tests seem to be a good choice.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635599602

From dholmes at openjdk.org  Wed Feb  5 03:38:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 03:38:27 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
 <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
 <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>
Message-ID: <hC_wgfWzoyRyhcflafpaCTLsRnvxFGI_uoDf6PC0Xvs=.ac840444-5276-482b-a642-5469e8d993a9@github.com>

On Tue, 4 Feb 2025 16:29:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> On closer inspection bytecodeInterpreterWithChecks.cpp might be a remnant of the old Interpreter that no longer exists. Alright, this should be ok then
>
> I think bytecodeInterpreterWithChecks was removed a long time ago. It is still referenced in 8u-dev: https://github.com/openjdk/jdk8u-dev/blob/master/hotspot/src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
> I guess that both interpreter excludes could be removed from `JVM_PRECOMPILED_HEADER_EXCLUDE`. @coleenp may know more.

As I reported elsewhere, `bytecodeInterpreterWithChecks.cpp` was a generated file for use with JVMTI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1942200561

From dholmes at openjdk.org  Wed Feb  5 03:53:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 03:53:15 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <GK-c39LN-3-Snh9btlVVK2MOwliFViK8CCYU0jtRAF8=.0972ebcc-8e88-4614-a799-185b5160f910@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

Just to repeat the essence of something made clear in the JBS issue, if we compile a file with different flags compared to the PCH file (precompiled.hpp) then we have to disable PCH for those files as PCH requires that the "same"** flags have to be used. So the old code has been incorrect in that regard.

** gcc has some specific rules about some flags that must match (e.g. -m ) but it somewhat hedges its bets on whether other flags, like optimization flags, need to be the exactly the same. So much easier for us to say they must be the same and so any files for which the flags are customized are excluded from PCH.

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

PR Comment: https://git.openjdk.org/jdk/pull/23442#issuecomment-2635641583

From jiangli at openjdk.org  Wed Feb  5 04:02:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 5 Feb 2025 04:02:13 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
Message-ID: <9sSVmY9slBPQpeUstbjzS7VurCl-ADBk5qYuu_oe20c=.c1159ed4-9f45-42fa-86e0-3e011279c114@github.com>

On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
> 
> Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard.

Other possible examples could be running the test on different JVM implementation (e.g. non-hotspot) that does not have libjvm.so.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2635649103

From dholmes at openjdk.org  Wed Feb  5 04:10:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 04:10:11 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <hC_wgfWzoyRyhcflafpaCTLsRnvxFGI_uoDf6PC0Xvs=.ac840444-5276-482b-a642-5469e8d993a9@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
 <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
 <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>
 <hC_wgfWzoyRyhcflafpaCTLsRnvxFGI_uoDf6PC0Xvs=.ac840444-5276-482b-a642-5469e8d993a9@github.com>
Message-ID: <h8zNuE4rsSuAn8aTwQl5Bcy8yCWxwe40owraRlbUJwg=.7566000b-9e3b-4a7c-a804-4e781550f52a@github.com>

On Wed, 5 Feb 2025 03:35:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think bytecodeInterpreterWithChecks was removed a long time ago. It is still referenced in 8u-dev: https://github.com/openjdk/jdk8u-dev/blob/master/hotspot/src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml
>> I guess that both interpreter excludes could be removed from `JVM_PRECOMPILED_HEADER_EXCLUDE`. @coleenp may know more.
>
> As I reported in JBS, `bytecodeInterpreterWithChecks.cpp` was a generated file for use with JVMTI.

There was no indication as to why `bytecodeInterpreter.cpp` was made no-PCH back in [JDK-6571248](https://bugs.openjdk.org/browse/JDK-6571248), and it appears to only have been for Windows. So removing it now seems reasonable, though we should be able to verify that the object file remains the same regardless, just to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1942217621

From jwaters at openjdk.org  Wed Feb  5 06:38:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Feb 2025 06:38:12 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <h8zNuE4rsSuAn8aTwQl5Bcy8yCWxwe40owraRlbUJwg=.7566000b-9e3b-4a7c-a804-4e781550f52a@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
 <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
 <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>
 <hC_wgfWzoyRyhcflafpaCTLsRnvxFGI_uoDf6PC0Xvs=.ac840444-5276-482b-a642-5469e8d993a9@github.com>
 <h8zNuE4rsSuAn8aTwQl5Bcy8yCWxwe40owraRlbUJwg=.7566000b-9e3b-4a7c-a804-4e781550f52a@github.com>
Message-ID: <tDnC5gMyDnSrTKjpn9BJBA0ftXTeBNfVeypm08vOCPY=.b9e8de32-c9a7-44e0-b1d1-7678ff97c3de@github.com>

On Wed, 5 Feb 2025 04:07:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As I reported in JBS, `bytecodeInterpreterWithChecks.cpp` was a generated file for use with JVMTI.
>
> There was no indication as to why `bytecodeInterpreter.cpp` was made no-PCH back in [JDK-6571248](https://bugs.openjdk.org/browse/JDK-6571248), and it appears to only have been for Windows. So removing it now seems reasonable, though we should be able to verify that the object file remains the same regardless, just to be safe.

I don't think that is possible, you cannot compile a Zero VM on Windows, so it will not be possible to tell whether the object file on Windows has changed or not. I do have a Windows/Zero port downstream, but haven't gotten around to fixing it on top of latest JDK yet

Is bytecodeInterpreterWithChecks.cpp still used by JVMTI now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1942317141

From mbaesken at openjdk.org  Wed Feb  5 08:08:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 08:08:14 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <tQbOuP5tGC8M2iPes_V-YcdN7aWP1nzR1i5rWLlhgQU=.963a0181-e819-4d21-92db-c0a60edbe368@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2636012459

From mbaesken at openjdk.org  Wed Feb  5 08:08:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 08:08:14 GMT
Subject: Integrated: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
Message-ID: <C1-s8woLMhQEzmTOKoSg2FRw5MZF4o6CZM2RfYnezts=.19b6e00d-5aba-4d09-96c0-0b36c1d42dd8@github.com>

On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Looks like the binary size optimization flags are not ideal when compiling with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in most cases to smaller libraries. On MSVC this seems to be not the case, the libs often get larger when optimizing for SIZE.
> 
> For example jvm.dll (build with VS2022) with current -Os size optimization
> 20M images/jdk/bin/server/jvm.dll
> 
> with -O1 set for size optimization
> 13M images/jdk/bin/server/jvm.dll
> 
> See the doc from MSVC about "optimize for size"
> https://learn.microsoft.com/en-us/cpp/build/reference/o1-o2-minimize-size-maximize-speed?view=msvc-170
> "The /O1 option sets the individual optimization options that create the smallest code in the majority of cases."
> The Os option is only a part of the size minimization flag set :
> /O1 (Minimize Size) equivalent to /Og /Os /Oy /Ob2 /GF /Gy

This pull request has now been integrated.

Changeset: 40603a5b
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40603a5bf039eef03c157bfc49ac8ea2229a94de
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8349214: Improve size optimization flags for MSVC builds

Reviewed-by: djelinski, ihse

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

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

From mbaesken at openjdk.org  Wed Feb  5 08:15:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 08:15:18 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <ICOFIDpU1gEH-bhiSLUXYcXT57gu9Oh4KdYnwKI7cT8=.0b39897b-15e2-43b6-b73e-66a6d58da975@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

Builds and tests look good on all platforms with this change so if there are no objections, I'll integrate it later today!

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

PR Comment: https://git.openjdk.org/jdk/pull/23442#issuecomment-2636026709

From mbaesken at openjdk.org  Wed Feb  5 08:30:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 08:30:14 GMT
Subject: RFR: 8349214: Improve size optimization flags for MSVC builds
In-Reply-To: <a0d-uvgShpI6zXUK5a47XDIoqXNiraUA-7buChYt1ng=.9d591ef8-e0d0-4f54-87b0-569311948b79@github.com>
References: <dJ0HWE_AvLzbAbTIljn8B8VdQ7HxLew1JposHTXOj6M=.665ec299-3e67-4e5f-b4c3-4f9dd883f3a4@github.com>
 <a0d-uvgShpI6zXUK5a47XDIoqXNiraUA-7buChYt1ng=.9d591ef8-e0d0-4f54-87b0-569311948b79@github.com>
Message-ID: <6t-xkV5FqR_6R_a_hOyDk5ME9LGqVbcv2ocppEIQXVY=.39870c97-0aec-418e-8d93-8dc256a649c1@github.com>

On Tue, 4 Feb 2025 21:03:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Sounds good then.
> 
> The optimization levels were kind of a mess that we "inherited" from the old build system, were they had just agglutinated over the years, probably dating back to Java 1.0, with nobody left around to remember why they were the way they were.
> 
> So it is definitely ripe for an overhaul. Anything you can do in this area is much appreciated, as long as it does not cause any regressions.

Thanks for the clarification !
Given that on Windows we compiled all the (JDK) native libraries with OPTIMIZATION setting LOW  in fact with O1 (minimize size / create the smallest code in the majority of cases) for years, there is a high chance that  size-optimization would work nicely for those (level LOW) too on platforms with gcc/clang ; but to be on the safe side we probably have to look into it on a per library level instead of just change it for all.

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

PR Comment: https://git.openjdk.org/jdk/pull/23432#issuecomment-2636053637

From stefank at openjdk.org  Wed Feb  5 08:53:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Feb 2025 08:53:20 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <mcpqhke7f3Jhgu0oQMvjkL1C0cQYGmK4UtnksEmX0X0=.7b9aca6e-2665-4967-91b4-e5cd40731a13@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
 <mcpqhke7f3Jhgu0oQMvjkL1C0cQYGmK4UtnksEmX0X0=.7b9aca6e-2665-4967-91b4-e5cd40731a13@github.com>
Message-ID: <2rPnjlXTdPQIsaQNDq7sA69p8YySeLVN896QgU9ABWY=.e2ac8773-7e8d-45bc-85ef-c8bc7d878ae7@github.com>

On Wed, 5 Feb 2025 01:42:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update hotspot-style.md
>>  - Update hotspot-style.html
>
> doc/hotspot-style.html line 213:
> 
>> 211: <li><p>Put conditional inclusions (`#if ...`) at the end of the section of HotSpot
>> 212: include lines. This also applies to macro-expanded includes of platform
>> 213: dependent files.</p></li>
> 
> What is the order for the conditional sections? Alphabetic on the include guard?

I don't think there's a set order. I wouldn't mind making it alphabetic with platforms includes coming before the other conditional includes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1942464083

From stefank at openjdk.org  Wed Feb  5 08:53:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Feb 2025 08:53:20 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <2rPnjlXTdPQIsaQNDq7sA69p8YySeLVN896QgU9ABWY=.e2ac8773-7e8d-45bc-85ef-c8bc7d878ae7@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
 <mcpqhke7f3Jhgu0oQMvjkL1C0cQYGmK4UtnksEmX0X0=.7b9aca6e-2665-4967-91b4-e5cd40731a13@github.com>
 <2rPnjlXTdPQIsaQNDq7sA69p8YySeLVN896QgU9ABWY=.e2ac8773-7e8d-45bc-85ef-c8bc7d878ae7@github.com>
Message-ID: <mMN94aSLZeWNFSJV1ziOWL-CkgyTieZqAhf4wo-hzcE=.49c3b349-2522-4be4-817c-2a2bc1336e4b@github.com>

On Wed, 5 Feb 2025 08:49:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> doc/hotspot-style.html line 213:
>> 
>>> 211: <li><p>Put conditional inclusions (`#if ...`) at the end of the section of HotSpot
>>> 212: include lines. This also applies to macro-expanded includes of platform
>>> 213: dependent files.</p></li>
>> 
>> What is the order for the conditional sections? Alphabetic on the include guard?
>
> I don't think there's a set order. I wouldn't mind making it alphabetic with platforms includes coming before the other conditional includes.

FWIW, I also tend to sort the forward declarations but that's also not something that everyone does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1942464777

From ihse at openjdk.org  Wed Feb  5 11:20:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Feb 2025 11:20:24 GMT
Subject: Integrated: 8348190: Framework for tracing makefile inclusion and
 parsing
In-Reply-To: <aVZWSShwSSRuV7dA6Y-rd9LpHIwlHMklJ3suQkfQK9c=.f1785f9b-7459-487f-a457-a5c1557ff94b@github.com>
References: <aVZWSShwSSRuV7dA6Y-rd9LpHIwlHMklJ3suQkfQK9c=.f1785f9b-7459-487f-a457-a5c1557ff94b@github.com>
Message-ID: <t2S8vIPn9gXYMvOKD3CP9YvFVJTZhS1e1apiJDC4MWE=.c234d0af-9816-4f0b-a128-754bbd6f6080@github.com>

On Fri, 31 Jan 2025 17:45:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A major problem when debugging the build system is figuring out what makefiles are evaluated, and in which order. 
> 
> Our makefiles comes in three flavors, which I have termed "files", "includes" and "snippets", for the purpose of being able to reason about them. The difference is this:
> * "files" (that is, "top-level files") are run directly by calling `make -f FooFile.gmk`
> * "includes" are included by other makesfiles using `include FooInclude.gmk`
> * "snippets" are automatically included by the framework, based on special naming rules
> 
> This patch adds a systematic structure to files, includes and snippets, which allows for a logging framework to be attached.
> 
> The log will look something like this:
> 
> 
> :Enter Main.gmk
> :    Enter common/MakeBase.gmk [include]
> :         Enter common/Utils.gmk [include]
> :         Leave common/Utils.gmk
> :         Enter common/FileUtils.gmk [include]
> :         Leave common/FileUtils.gmk
> :    Leave common/MakeBase.gmk
> :    Enter MainSupport.gmk [include]
> :    Leave MainSupport.gmk
> :    Enter common/FindTests.gmk [include]
> :    Leave common/FindTests.gmk
> :    Enter common/Modules.gmk [include]
> :    Leave common/Modules.gmk
> :Leave Main.gmk [now executing rules]
> 
> 
> Furthermore, this patch achieves a secondary benefit, which is arguably just as important, and that is simplifying the boilerplate in makefiles. I am not saying that it offers strictly *less* boilerplate -- in some cases, it is actually more than what we have right now. But it does offer *systematic* boilerplate. You only have to include the proper start/end makefile and then you're good to go. These start/end files implements the best practices that have evolved over the year (like include guards for includes), and standards we employ in the JDK build system (like always starting with a `default: all` rule). It became painfully obvious when implementing this PR that our adherence to these best practices are sketchy, at best. From now on, it will not be possible to miss declaring best practice boilerplate, since it is all concentrated in a single set of files.
> 
> While updating all makefiles to use these new systematic start/end includes, I took the opportunity to clean up the style used and make it more consistent. So now all makefiles follows this pattern (as far as applicable):
> 
> include Make[File/Include]Start.gmk
> 
> ################################################################################
> # High-level description of this file (if present).
> #############################...

This pull request has now been integrated.

Changeset: 61465883
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61465883b465a184e31e7a03e2603d29ab4815a4
Stats:     2701 lines in 273 files changed: 1647 ins; 485 del; 569 mod

8348190: Framework for tracing makefile inclusion and parsing

Reviewed-by: erikj

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

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

From stuefe at openjdk.org  Wed Feb  5 12:07:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 5 Feb 2025 12:07:11 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <mMN94aSLZeWNFSJV1ziOWL-CkgyTieZqAhf4wo-hzcE=.49c3b349-2522-4be4-817c-2a2bc1336e4b@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
 <mcpqhke7f3Jhgu0oQMvjkL1C0cQYGmK4UtnksEmX0X0=.7b9aca6e-2665-4967-91b4-e5cd40731a13@github.com>
 <2rPnjlXTdPQIsaQNDq7sA69p8YySeLVN896QgU9ABWY=.e2ac8773-7e8d-45bc-85ef-c8bc7d878ae7@github.com>
 <mMN94aSLZeWNFSJV1ziOWL-CkgyTieZqAhf4wo-hzcE=.49c3b349-2522-4be4-817c-2a2bc1336e4b@github.com>
Message-ID: <SNN_NfUCDVATA423ujajMBTsGNG2U6gXL_CS-1j4Xqw=.3a47c308-bbfd-494f-a07b-582411748c87@github.com>

On Wed, 5 Feb 2025 08:50:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> FWIW, I also tend to sort the forward declarations but that's also not something that everyone does.

I, too, am an obsessive sorter. Clean code is good code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1942751804

From jsjolen at openjdk.org  Wed Feb  5 12:42:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Feb 2025 12:42:13 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <1gOEDAkU1eGcUnYqPawR3g5OqAseBiVIVPUIi4O9GYc=.321e1b86-3c6f-4c92-8036-27240a778659@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <9RwWVrZpTqsRO5srrrT0jOt4CGc7oF5FEm06Pzjf2yI=.a5fc3070-226c-4292-9802-426c9cab1672@github.com>
 <eF88iMTl6J-Wl5Sygf3UqVKE9EzAo1TehF6-boPrdfM=.88524e99-395c-43dd-8256-1abacabb3f58@github.com>
 <1gOEDAkU1eGcUnYqPawR3g5OqAseBiVIVPUIi4O9GYc=.321e1b86-3c6f-4c92-8036-27240a778659@github.com>
Message-ID: <y3C_wiAtsyxXAZmgIjtN0XnKpnCdNysa81Pt3qBxxJk=.9ea29f9b-b2a4-4d9e-b3e8-984f4ea8c430@github.com>

On Mon, 3 Feb 2025 12:14:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>>> A lot of these rules looks like they could be checked with some simple scripting or additions to jcheck. Have you considered that?
>> 
>> I haven't felt the urge to write such a script, but I know that others have scripts to sort the includes.
>
>> I haven't felt the urge to write such a script, but I know that others have scripts to sort the includes
> 
> Ok, it was just a suggestion. My experience is that while clearly written conventions/rules are important, the more they can be automated, the less hassle for everyone.

@dougxc,

We could use clang-format for these specific include rules.

For example, when we still had `precompiled.hpp` I had this in my `.clang-format` file:


IncludeCategories: # precompiled.hpp ALWAYS first
  - Regex: 'precompiled.hpp'
    Priority: 0
    SortPriority: 0


Implementing all of the rules for Clang format is left as an exercise to the reader, and the author would be very appreciative if someone posted their solution here :-).

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

PR Comment: https://git.openjdk.org/jdk/pull/23388#issuecomment-2636674949

From mbaesken at openjdk.org  Wed Feb  5 13:47:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 13:47:16 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <C2jji5UHIc98vnELhGJm2JnRniwR86Z72UFlHKXyW1c=.ebf7130b-b2ed-463e-a4c1-25d18e3a207b@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
 <C2jji5UHIc98vnELhGJm2JnRniwR86Z72UFlHKXyW1c=.ebf7130b-b2ed-463e-a4c1-25d18e3a207b@github.com>
Message-ID: <9EBd4_uzR14Jk6dLeU0EcvLaDXZRTqGj5X9L96ajSyc=.d65857d8-bd69-46a2-b1d0-c577df8525c9@github.com>

On Wed, 29 Jan 2025 23:25:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  (hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

That does not work/compile,  it leads to 


make java.desktop-libs-only JOBS=1 LOG=info
Generating main target list
Running make as 'make JOBS=1 LOG=info java.desktop-libs-only'
Building target 'java.desktop-libs-only' in configuration '/myjdk'
Creating support/modules_libs/java.desktop/libawt.so from 72 file(s)
Compiling AlphaMacros.c (for libawt.so)
In file included from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.h:29,
                 from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.c:26:
/myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h:36:10: fatal error: java_awt_AlphaComposite.h: No such file or directory


Seems the dependencies do not work for some reason, so I need to build  the whole jdk with LOG=info I guess.

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2636895021

From erikj at openjdk.org  Wed Feb  5 14:14:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Feb 2025 14:14:15 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
Message-ID: <GzWcs5f1WSEYzMywz-ey1JZQDoMswQaDzjpfNv6MewQ=.fc4279b4-1c9a-4da6-9349-e0711e2eb1df@github.com>

On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting.

> > (hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

> Seems the dependencies do not work for some reason, so I need to build the whole jdk with LOG=info I guess.

Adding the `-only` suffix does indeed disable dependencies, so you have to manually set up your build directory state to have all the dependencies built already. This would be a reasonable sequence for getting relevant timings. First make sure all dependencies have been built:


$ make java.desktop-libs

Then delete only the things you want to rebuild and run the part of the build that is relevant. This can be repeated.

$ rm -rf build/<your-build-dir>/support/modules_libs/java.desktop
$ time make java.desktop-libs-only JOBS=1

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2636960207

From ihse at openjdk.org  Wed Feb  5 15:20:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Feb 2025 15:20:15 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <qZbK6UEuLqTCsn9P2bfUM2IF7Kd1kTjE6qlcsB5GWSo=.ad3ee3fc-32d7-450d-9e6f-324cbaa9d7cb@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

LGTM

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23442#pullrequestreview-2596139363

From jiangli at openjdk.org  Wed Feb  5 19:51:49 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 5 Feb 2025 19:51:49 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
Message-ID: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>

Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.

A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 

GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

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

Commit messages:
 - Set matrix.
 - Remove debug build for now.
 - Set debug-levels to "release".
 - Set debug-levels to "debug".
 - Add build-linux-static.yml.
 - Add build-linux-static.yml.
 - Add build-linux-x64-static build job in GHA.

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

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

From jwilhelm at openjdk.org  Wed Feb  5 23:43:52 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 5 Feb 2025 23:43:52 GMT
Subject: [jdk24] RFR: 8345276: Remove EA from the JDK 24 version string with
 first RC promotion
Message-ID: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>

8345276: Remove EA from the JDK 24 version string with first RC promotion

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

Commit messages:
 - 8345276: Remove EA from the JDK 24 version string with first RC promotion

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

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

From darcy at openjdk.org  Wed Feb  5 23:43:53 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Feb 2025 23:43:53 GMT
Subject: [jdk24] RFR: 8345276: Remove EA from the JDK 24 version string
 with first RC promotion
In-Reply-To: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
References: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
Message-ID: <paDJ43o9BhSVzpnEnMF_QcacErdgXigXAqZg-NSYnXg=.6d1521b2-1301-44c6-b6e7-a21032cd5e6e@github.com>

On Wed, 5 Feb 2025 23:32:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8345276: Remove EA from the JDK 24 version string with first RC promotion

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23477#pullrequestreview-2597233286

From mikael at openjdk.org  Wed Feb  5 23:43:53 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 5 Feb 2025 23:43:53 GMT
Subject: [jdk24] RFR: 8345276: Remove EA from the JDK 24 version string
 with first RC promotion
In-Reply-To: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
References: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
Message-ID: <ofNxr0a0GxpDb8FDYa9ZWD9gicpkqJNtk3StjZUEH2Y=.ce4d872f-0e96-4d4d-aaed-2d3e5b7f632c@github.com>

On Wed, 5 Feb 2025 23:32:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8345276: Remove EA from the JDK 24 version string with first RC promotion

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23477#pullrequestreview-2597233920

From erikj at openjdk.org  Wed Feb  5 23:59:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Feb 2025 23:59:09 GMT
Subject: [jdk24] RFR: 8345276: Remove EA from the JDK 24 version string
 with first RC promotion
In-Reply-To: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
References: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
Message-ID: <ITZvHy3RSzgz1ms8N4qZW_9LS9E57HCImXoCYp7j8hw=.e4887a4a-4a17-442e-8077-84b32d465d5c@github.com>

On Wed, 5 Feb 2025 23:32:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8345276: Remove EA from the JDK 24 version string with first RC promotion

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23477#pullrequestreview-2597252959

From jwilhelm at openjdk.org  Thu Feb  6 00:19:15 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 6 Feb 2025 00:19:15 GMT
Subject: [jdk24] Integrated: 8345276: Remove EA from the JDK 24 version string
 with first RC promotion
In-Reply-To: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
References: <pd0dIBvJ6_ZMcnRVqtkaVslKGO7WgAeFiGTNEwPDAB4=.a5ff86f8-6b46-46cb-ba1e-22dd179483f8@github.com>
Message-ID: <DCmCpf5wpyMWXQP6tD-dMNhWQpgN1zaXD2snNlmTzwc=.c3ef42e6-18c0-4144-ae97-4f04c5f2ae66@github.com>

On Wed, 5 Feb 2025 23:32:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8345276: Remove EA from the JDK 24 version string with first RC promotion

This pull request has now been integrated.

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

8345276: Remove EA from the JDK 24 version string with first RC promotion

Reviewed-by: darcy, mikael, erikj

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

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

From jiangli at openjdk.org  Thu Feb  6 01:48:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 01:48:07 GMT
Subject: RFR: 8349513: Remove unused
 BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads
Message-ID: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>

Please review this minor cleanup. The related jtreg test, TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by https://github.com/openjdk/jdk/pull/21565 work (for [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383)).

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

Commit messages:
 - Remove unused BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads.

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

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

From dholmes at openjdk.org  Thu Feb  6 01:52:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 01:52:57 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and
 parsing
Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.

JDK-8348190: Framework for tracing makefile inclusion and parsing

The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.

Thanks.

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

Commit messages:
 - Revert "8348190: Framework for tracing makefile inclusion and parsing"

Changes: https://git.openjdk.org/jdk/pull/23481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349511
  Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod
  Patch: https://git.openjdk.org/jdk/pull/23481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481

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

From darcy at openjdk.org  Thu Feb  6 02:04:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Feb 2025 02:04:15 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Approving clean backout.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613

From dholmes at openjdk.org  Thu Feb  6 02:44:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:44:08 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
Message-ID: <AWJoVSTeygOR6BO1A3fQOGLPGVzlF6zuRNMw4TMiVZc=.cf4c9f9e-75b8-45ef-b295-8fb57846fa24@github.com>

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Approving clean backout.

Thanks @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813

From mikael at openjdk.org  Thu Feb  6 02:54:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Feb 2025 02:54:17 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
Message-ID: <o_LWA-N7-KZ6e3MLu8U2GOcgFRK6rgW58IWj5sGK_6s=.12f73a3c-70ce-49c3-b486-1585990fefac@github.com>

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Marked as reviewed by mikael (Reviewer).

Thanks @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: Integrated: 8349511: [BACKOUT] Framework for tracing makefile
 inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <aWuh7nyeGLH2h82Pk0IN4KD8wwSrAXkioaZ_EWlOWN4=.5e1f6202-37f7-4b5a-a36a-2adf4ca85b10@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 64bd8d25
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2
Stats:     2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod

8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

Reviewed-by: darcy, mikael

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

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

From dholmes at openjdk.org  Thu Feb  6 07:28:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 07:28:12 GMT
Subject: RFR: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tDnC5gMyDnSrTKjpn9BJBA0ftXTeBNfVeypm08vOCPY=.b9e8de32-c9a7-44e0-b1d1-7678ff97c3de@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
 <yYzE7iqNXjHqfb7B89ZngiPjOyrl7UjlYyOydTH5aPc=.7794328c-f5f0-4cbf-834f-f5dfcbf6eff7@github.com>
 <zd-C8l4cLcHYYffyhYuOowMVhUfPptikHIDD-1IyCDQ=.6f68a574-2c14-4636-af45-6d32d6c9726e@github.com>
 <D3rJZBJGaEoAXIPQjIrl-1_cS66SzIH2yALP96S5pfA=.14e0726e-17d1-4802-b3ae-4b64a8c266fe@github.com>
 <FzEtD3H7uYi5VnGQHscQKBY6XB7lp8uxCpN_4nlWcig=.9422b55f-997e-459c-9c76-cac0d91952b6@github.com>
 <hC_wgfWzoyRyhcflafpaCTLsRnvxFGI_uoDf6PC0Xvs=.ac840444-5276-482b-a642-5469e8d993a9@github.com>
 <h8zNuE4rsSuAn8aTwQl5Bcy8yCWxwe40owraRlbUJwg=.7566000b-9e3b-4a7c-a804-4e781550f52a@github.com>
 <tDnC5gMyDnSrTKjpn9BJBA0ftXTeBNfVeypm08vOCPY=.b9e8de32-c9a7-44e0-b1d1-7678ff97c3de@github.com>
Message-ID: <5G6w0Ljftk7AwO9AbO20n0n2KxJAB1AftylOYvQcJGI=.67a02188-e160-48ec-8563-a171004b7a67@github.com>

On Wed, 5 Feb 2025 06:35:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> There was no indication as to why `bytecodeInterpreter.cpp` was made no-PCH back in [JDK-6571248](https://bugs.openjdk.org/browse/JDK-6571248), and it appears to only have been for Windows. So removing it now seems reasonable, though we should be able to verify that the object file remains the same regardless, just to be safe.
>
> I don't think that is possible, you cannot compile a Zero VM on Windows, so it will not be possible to tell whether the object file on Windows has changed or not. I do have a Windows/Zero port downstream, but haven't gotten around to fixing it on top of latest JDK yet
> 
> Is bytecodeInterpreterWithChecks.cpp still used by JVMTI now?

bytecodeInterpreterWithChecks.cpp was removed some time ago.

If no one can even build Windows Zero today then we are not going to make anything worse

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23442#discussion_r1944226646

From mbaesken at openjdk.org  Thu Feb  6 08:12:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 08:12:17 GMT
Subject: Integrated: 8349140: Size optimization (opt-size) build fails after
 recent PCH changes
In-Reply-To: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
References: <tANKHHVSsVZjB3Z06oc9NfOrN76cEiBENhvY9fPdmGQ=.780bc482-9bdf-408a-abe0-011b4abc8dd5@github.com>
Message-ID: <iz1bkpPB9VneEVYD4v9MRsEGoTtRuZCKmQ6og2EjUGM=.f4a602ec-752f-4394-be0d-c9052f0ea124@github.com>

On Tue, 4 Feb 2025 15:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the configure flag --enable-jvm-feature-opt-size (linux x86_64 opt build, gcc 11 devkit) we run into this error after the recent PCH related changes :
> 
> 
> cc1plus: error: /build_optsize/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch: not used because `__OPTIMIZE_SIZE__' not defined [-Werror=invalid-pch]
> 
> + exit 1
> gmake[3]: *** [lib/CompileJvm.gmk:170: /build_optsize/hotspot/variant-server/libjvm/objs/allocation.o] Error 1
> 
> 
> Please note that allocation.cpp is currently in the list of `OPT_SPEED_SRC` files (means - files to be optimized for speed even in case of SIZE optimization) :
> https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L196
> 
> Same issue can be observed on Windows x86_64 (VS2022 used).

This pull request has now been integrated.

Changeset: 3eb57f6d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3eb57f6d46b4375cb02b575739a1c12f71e088cf
Stats:     18 lines in 1 file changed: 1 ins; 12 del; 5 mod

8349140: Size optimization (opt-size) build fails after recent PCH changes

Reviewed-by: jwaters, erikj, ihse

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

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

From dholmes at openjdk.org  Thu Feb  6 08:18:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 08:18:09 GMT
Subject: RFR: 8349513: Remove unused
 BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads
In-Reply-To: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
References: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
Message-ID: <fpynS9_EDupMX1KXHSNAi8moEmMPhAtguTR8o9Caa6Q=.f8639a68-9313-4526-ae4a-e2c1f0544c04@github.com>

On Thu, 6 Feb 2025 01:42:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this minor cleanup. The related jtreg test, TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by https://github.com/openjdk/jdk/pull/21565 work (for [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383)).

Looks good and trivial

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23482#pullrequestreview-2597949074

From mbaesken at openjdk.org  Thu Feb  6 09:03:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 09:03:25 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
Message-ID: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>

The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
The special settings were needed for ancient versions of xlC.

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

Commit messages:
 - JDK-8349375

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

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

From duke at openjdk.org  Thu Feb  6 11:49:14 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Thu, 6 Feb 2025 11:49:14 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v6]
In-Reply-To: <TZstHQXgXSakT_W13nr2Dda2C2jHBgyAVrEWSV_-Mv0=.9fff63a9-309f-4060-b091-f40e4b03e763@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <TZstHQXgXSakT_W13nr2Dda2C2jHBgyAVrEWSV_-Mv0=.9fff63a9-309f-4060-b091-f40e4b03e763@github.com>
Message-ID: <9p6OvKREPJYdRAkbiZ5IV80z22Y-Hc39hl-xGgxtqzU=.ea0371fe-9fbb-4df9-9803-1b03aea61288@github.com>

On Tue, 7 Jan 2025 09:04:28 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>  - adapt changes to the ancient awk on MacOS
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - indented the comment
>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>  - lowercased Jtreg. fixed typos in the comment
>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>  - 8343832: Enhance test summary with number of skipped tests

Don't close it just yet, bot.

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

PR Comment: https://git.openjdk.org/jdk/pull/22245#issuecomment-2639599689

From mdoerr at openjdk.org  Thu Feb  6 12:05:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 6 Feb 2025 12:05:14 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <GfdG1RCFIhRyNGkF2kWCO0DYH72G2zPaHqMp_OWU0V4=.5cdd535a-fd8f-4d1d-b056-b9020276b420@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23487#pullrequestreview-2598474809

From clanger at openjdk.org  Thu Feb  6 12:45:09 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 6 Feb 2025 12:45:09 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <bZRKXOL9DbbGmDuEgJis9sJNOO0rtNozPj2zgiqsHDM=.c8e1b766-65e7-4614-8c42-3d2215eed684@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23487#pullrequestreview-2598564444

From mbaesken at openjdk.org  Thu Feb  6 13:57:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 13:57:22 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
Message-ID: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>

The splashscreen lib is currently built with LOW optimization.
This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.

current settings (LOW optimization) :
---------------------------------------------------
2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so

468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM

368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo


new settings (SIZE optimization) :
--------------------------------------------------
2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so

404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM

372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo

On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
Other UNIX platforms have a reduction by ~ 10-20 % .
For Windows, LOW and SIZE optimization have currently the same O - flags so no reduction.

Build times are the same on Windows (because LOW and SIZE are currently 'optimize for size').
On Linux x86_64 it seems that the build times of java.desktop native libs get slightly better but only very little.

time make java.desktop-libs-only JOBS=1

LOW (current)
real   5m38.074s
user   4m16.709s
sys    0m26.335s

real   5m29.081s
user   4m17.838s
sys    0m26.749s

real   5m25.496s
user   4m17.906s
sys    0m25.506s

SIZE for libsplashscreen
real  5m18.468s
user  4m13.024s
sys   0m25.129s

real  5m31.944s
user  4m12.922s
sys   0m26.333s

real  5m12.874s
user  4m12.253s
sys   0m25.206s

real has a bit of variance but  user time is  4m16 / 4m17   for LOW  and  4m12/4m13  for SIZE for libsplashscreen.

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

Commit messages:
 - JDK-8349378

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

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

From erikj at openjdk.org  Thu Feb  6 14:03:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Feb 2025 14:03:16 GMT
Subject: RFR: 8349513: Remove unused
 BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads
In-Reply-To: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
References: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
Message-ID: <zkjHdUFt6GBO5_5iUUFXSXB0dtMPe7l6jjastsxXe64=.34aaca38-aa73-4919-82f4-bb210d491f3c@github.com>

On Thu, 6 Feb 2025 01:42:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this minor cleanup. The related jtreg test, TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by https://github.com/openjdk/jdk/pull/21565 work (for [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383)).

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23482#pullrequestreview-2598765565

From erikj at openjdk.org  Thu Feb  6 14:04:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Feb 2025 14:04:13 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <Fn3SRcOIWVUQsTBksglPYPGE6OVTDsQOpHUsaltyI2s=.7197266d-81da-4d89-b79b-3f64d653a854@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23487#pullrequestreview-2598768948

From erikj at openjdk.org  Thu Feb  6 14:06:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Feb 2025 14:06:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX platforms have a reduction by ~ 10-20 % .
> For Windows, LOW and SIZE optimization have currentl...

I think this looks good, but someone from client should probably also weigh in.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2598774548

From mbaesken at openjdk.org  Thu Feb  6 14:18:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 14:18:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <Ur1Tr3C85b7t-gBebU9s6AtUnQLUxD65E0Nz7lLnSl8=.64c496f3-6a6b-4bb6-b538-b7006fd195fd@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

For the record, those are the lib sizes on Windows x86_64, VS2019 (LOW and SIZE uses currently the same opt flag, so same sizes)

204K    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll
1.4M    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll.pdb
352K    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll.stripped.pdb

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2639948726

From jiangli at openjdk.org  Thu Feb  6 16:18:33 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 16:18:33 GMT
Subject: Integrated: 8349513: Remove unused
 BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads
In-Reply-To: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
References: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
Message-ID: <r7OOJeTPFxV1Liv830-J8wPkSt8y9kNL8cdw9oItQgY=.1bf82a5a-474a-4104-a1b4-278da814e257@github.com>

On Thu, 6 Feb 2025 01:42:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this minor cleanup. The related jtreg test, TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by https://github.com/openjdk/jdk/pull/21565 work (for [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383)).

This pull request has now been integrated.

Changeset: eb847026
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb84702626ef1ededc55969923958e8c2835d821
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8349513: Remove unused BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads

Reviewed-by: dholmes, erikj

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

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

From jiangli at openjdk.org  Thu Feb  6 16:18:32 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 16:18:32 GMT
Subject: RFR: 8349513: Remove unused
 BUILD_JDK_JTREG_LIBRARIES_JDK_LIBS_libTracePinnedThreads
In-Reply-To: <fpynS9_EDupMX1KXHSNAi8moEmMPhAtguTR8o9Caa6Q=.f8639a68-9313-4526-ae4a-e2c1f0544c04@github.com>
References: <GIEs0lHG6WWIyptZMcerKk6wyaRgQmIc30mIr8aXnEo=.5ab12787-83ec-4b8c-99a7-06d370bb8209@github.com>
 <fpynS9_EDupMX1KXHSNAi8moEmMPhAtguTR8o9Caa6Q=.f8639a68-9313-4526-ae4a-e2c1f0544c04@github.com>
Message-ID: <7m3lOBFrmwmOQG3sEXu7_gqc9dD5tjsvWt_hPahq_JE=.f7cd9ba0-5b91-4764-a0fb-6927bc3add1a@github.com>

On Thu, 6 Feb 2025 08:15:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this minor cleanup. The related jtreg test, TracePinnedThreads.java/libTracePinnedThreads.c has already been removed by https://github.com/openjdk/jdk/pull/21565 work (for [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383)).
>
> Looks good and trivial
> 
> Thanks

Thanks, @dholmes-ora and @erikj79.

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

PR Comment: https://git.openjdk.org/jdk/pull/23482#issuecomment-2640286203

From jiangli at openjdk.org  Thu Feb  6 16:57:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 16:57:09 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <19ixFJZcT0QN9VR-jGZ4rZ5qxOJ51U9ezmk1XXBxYzA=.0fa88acb-c554-4873-a614-3d335c4e6822@github.com>

On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

@erikj79 @magicus Could you help review the GHA change for adding a static-jdk-image build? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2640461545

From shade at openjdk.org  Thu Feb  6 17:04:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Feb 2025 17:04:10 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>

On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2640476955

From kbarrett at openjdk.org  Thu Feb  6 17:31:22 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 6 Feb 2025 17:31:22 GMT
Subject: RFR: 8348286: [AIX] clang 17 introduces new warning
 Wtentative-Definitions which produces Build errors [v3]
In-Reply-To: <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
References: <Y1MNMWR4cYqet2mgF9EgeWosB6eG5ImOVjyn3ncjAW8=.3a771b94-ba15-4e2d-a8ac-cc7aca483653@github.com>
 <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
Message-ID: <Sw25chLxLKYMumjFze-_j3-GhTkBcPC9uvhY85Wr8jE=.7620de53-cf27-4de9-9ca2-5cd0c8b1320d@github.com>

On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan.
>> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror.
>> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found:
>> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions]
>>    36 | IMGEXTERN jfieldID g_BImgRasterID;
>>       | ^
>> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g.
>> imageInitIDs.h:36:20
>>    36 extern jfieldID g_BImgRasterID;
>> and the corresponding c-File
>>    jfieldID g_BImgRasterID;
>> 
>> The other possible solution would be to compile everything with
>> -Wno-tentative-definitions
>> which could be set in flags-cflags.m4, if compiling with clang 17.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old solution

Coming late to the party, since this PR has already been integrated.

First, tentative definitions are only applicable to C, not to C++.

I think `-Wtentative-definition` doesn't really buy all that much. It looks
like it turns a *potential* link-time failure into a definite compile-time
warning. But I don't think I'd want to globally disable it, as it seems like
it would usually be a valid complaint (unless the code is jumping through some
hoops as done by imageInitIDs.[ch]), and probably provides a better error
message too.

gcc provides `-fcommon`, which controls the placement of tentative
definitions. We're not using that, instead implicitly using the default
`-fno-common`. (There is one place where we unnecessarily use `-fno-common`
explicitly: https://bugs.openjdk.org/browse/JDK-8349565.)

With `-fcommon`, tentative definitions in different translation units are
merged, with potential access penalties. With `-fno-common`, instead of
merging one gets multiple definition errors at link time. Note that code that
relies on `-fcommon` has never been standards compliant.

The changes related to fp_pipewire.h seem fine.

I'm not keen on the large copy-paste-modify for imageInitIDs.[ch]. I kind of
prefer a different approach, of locally suppressing the warning, i.e.
something like (untested, may need version conditionalization):

In imageInitIDs.c

+ PRAGMA_DIAG_PUSH
+ #pragma clang diagnostic ignored "-Wtentative-definition"
  #define IMGEXTERN
  #include "imageInitIDs.h"
+ PRAGMA_DIAG_POP


I'll leave it up to the client team to decide whether they want to make such a
change, or leave things as-is.

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

PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2640539884

From jiangli at openjdk.org  Thu Feb  6 18:52:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 18:52:09 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
Message-ID: <ym3ZGL1hjRZcmi_geb42Fz-BeUWDH5-HFc_VCX3_22k=.c05f9b0a-605c-48c7-9e15-419a1752499a@github.com>

On Thu, 6 Feb 2025 17:01:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?

@shipilev Thanks for looking into this.

> What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?

Currently, the main difference is avoiding building `static-libs-bundles` completely in `build-linux-static.yml`, since that's not needed for the testing purpose with `static-jdk-image`. In `build-linux.yml`, there is the following logic that skips building `static-libs-bundles` but for `fastdebug` build only. I actually initially started using `build-linux.yml` for the static build job, but later added `build-linux-static.yml` when I was looking for a cleaner way to skipping building `static-libs-bundles`. 


          # Only build static-libs-bundles for release builds.
          # For debug builds, building static-libs often exceeds disk space.
          STATIC_LIBS: ${{ matrix.debug-level == 'release' && 'static-libs-bundles' }}

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2640726063

From jiangli at openjdk.org  Thu Feb  6 20:18:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 20:18:22 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
Message-ID: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>

This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.

There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

Commit messages:
 - - Don't explicitly link with libjvm.so for libExplicitAttach. That helps to avoid adding libjvm.so as a dependency for libExplicitAttach.so.

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

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

From jiangli at openjdk.org  Thu Feb  6 20:26:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 20:26:16 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
Message-ID: <oMdGqYGcNQEDAzyle1XxSjM_7rVJXQupnVM23XByagQ=.300ac7ef-712b-42ed-8c56-78442d807c56@github.com>

On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
>
>> Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
> 
> Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard.

@dholmes-ora and @AlanBateman Could you please review and approve the change if there's no additional concerns? I also sent out https://github.com/openjdk/jdk/pull/23500, which applies the same principle to fix libExplicitAttach issue.

I'm also in the process of adding the VMProps for static JDK as @AlanBateman suggested. That's needed to skip the tests require accessing tools in `bin/`, until we have a clear story on the tools support for static JDK/hermetic Java (that topic has been brought up in the hermetic Java meetings).

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2640918286

From kbarrett at openjdk.org  Thu Feb  6 20:56:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 6 Feb 2025 20:56:15 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering [v2]
In-Reply-To: <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
 <wYtlLmrtTAuMTFbTJ0bTKttW1J4L3LRSyh9wEOlqgeo=.b8203c4c-7e20-4dd7-98cb-4c17458d03bd@github.com>
Message-ID: <XKG-MYBommXkhVOXcyBCkUmgeNHrCrjhUcdWM_5caw4=.8fb2bf62-7487-4013-9866-458120dc902d@github.com>

On Mon, 3 Feb 2025 12:14:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
>> 
>> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
>> 
>> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
>> 
>> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update hotspot-style.md
>  - Update hotspot-style.html

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23388#pullrequestreview-2599902569

From jwaters at openjdk.org  Fri Feb  7 05:31:14 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Feb 2025 05:31:14 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <enNwxYuD3zdrh1_2EK4-KtGP4qH4G0ZIIn0pijBYaCU=.62d385b9-dd94-48d3-b9ac-8786e3425c2b@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

AIX is typically not under my area of knowledge, but this looks good and simple enough

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23487#pullrequestreview-2600833246

From mbaesken at openjdk.org  Fri Feb  7 07:49:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 07:49:55 GMT
Subject: RFR: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <9GB9kUF5Quz3db8rtukKSxmezTko4AAmGZ9vIG1Yyps=.ea734db5-c883-47ba-aac0-887cf10bffbe@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23487#issuecomment-2642153219

From mbaesken at openjdk.org  Fri Feb  7 07:49:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 07:49:56 GMT
Subject: Integrated: 8349375: Cleanup AIX special file build settings
In-Reply-To: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
References: <fZhhrCE2cZsv23zMfrWEl_CLeLZOlJj5WnKgs5i-I-4=.ab020294-adda-4379-9f05-d3ab8756fc65@github.com>
Message-ID: <RdXez5kv-sTaVVZS00IbIdcwZCjDPLnA3drKKIkEUas=.0395a6e0-9e2d-4ae1-94e6-0f4b041660ea@github.com>

On Thu, 6 Feb 2025 08:58:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The special optimization settings for  jvmtiEnterTrace.cpp on AIX can be removed ; the file compiles now some seconds with or without this workaround.
> The special settings were needed for ancient versions of xlC.

This pull request has now been integrated.

Changeset: 006ed5c0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/006ed5c02b47d12fdcc070f50cfeb77d5c158bca
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8349375: Cleanup AIX special file build settings

Reviewed-by: mdoerr, clanger, erikj, jwaters

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

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

From alanb at openjdk.org  Fri Feb  7 10:41:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Feb 2025 10:41:00 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>

On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

Can you look at adding native init method instead? This could be called from the System.loadLibraray and avoid introduce a side effect of startThreads initialising GetCreatedJavaVMs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2642552698

From mbaesken at openjdk.org  Fri Feb  7 10:54:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 10:54:10 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
Message-ID: <GRo80sk7wuvZD6FGwsCDd3G3ZvZ2FzlnNii-V2VWMt8=.f17faf4e-233c-46d4-8608-c52be65bb74e@github.com>

On Thu, 6 Feb 2025 14:03:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The splashscreen lib is currently built with LOW optimization.
>> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
>> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
>> 
>> current settings (LOW optimization) :
>> ---------------------------------------------------
>> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
>> 
>> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> 
>> new settings (SIZE optimization) :
>> --------------------------------------------------
>> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
>> 
>> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> On Linux aarch64 only the debuginfo shrinks but the lib stays abo...
>
> I think this looks good, but someone from client should probably also weigh in.

Hi @erikj79  thanks for the review !

@magicus , @mrserb , @honkar-jdk  any comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2642577698

From ihse at openjdk.org  Fri Feb  7 13:11:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Feb 2025 13:11:16 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

What tests have you run?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2642863817

From ihse at openjdk.org  Fri Feb  7 13:17:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Feb 2025 13:17:17 GMT
Subject: RFR: 8348286: [AIX] clang 17 introduces new warning
 Wtentative-Definitions which produces Build errors [v3]
In-Reply-To: <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
References: <Y1MNMWR4cYqet2mgF9EgeWosB6eG5ImOVjyn3ncjAW8=.3a771b94-ba15-4e2d-a8ac-cc7aca483653@github.com>
 <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
Message-ID: <WDYNPWYMFKfxih_Lk45l_UuXionPmR26TYneKqgLRA4=.58403f7c-93e7-40f8-8880-ebde14d36830@github.com>

On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan.
>> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror.
>> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found:
>> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions]
>>    36 | IMGEXTERN jfieldID g_BImgRasterID;
>>       | ^
>> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g.
>> imageInitIDs.h:36:20
>>    36 extern jfieldID g_BImgRasterID;
>> and the corresponding c-File
>>    jfieldID g_BImgRasterID;
>> 
>> The other possible solution would be to compile everything with
>> -Wno-tentative-definitions
>> which could be set in flags-cflags.m4, if compiling with clang 17.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old solution

> I think `-Wtentative-definition` doesn't really buy all that much. [...] But I don't think I'd want to globally disable it, as it seems like it would usually be a valid complaint

I think we all agree on that. Apparently clang 17 enables it by default, at least on AIX. So then we have the choice to either disable it or accept to have it on, and deal with what it complains about. 

These were the only problematic places in the entire code base. I think it was the right decision to change the code in these places. The code here was, if not "smelly" so at least not conforming to the practice used everywhere else in the code base. I personally think your workaround with disabling the warning seems like a worse solution compared to what was actually integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2642875242

From mbaesken at openjdk.org  Fri Feb  7 14:14:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 14:14:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
Message-ID: <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>

On Fri, 7 Feb 2025 13:08:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> What tests have you run?

Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
However I think I have to run some more manual tests on client  like  setups.

Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2643047402

From jiangli at openjdk.org  Fri Feb  7 20:10:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 20:10:02 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  Move JNI_GetCreatedJavaVMs lookup into JNI_OnLoad, to address AlanBateman's suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/b68f76b2..4ee170d2

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

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

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

From jiangli at openjdk.org  Fri Feb  7 20:13:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 20:13:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
Message-ID: <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>

On Fri, 7 Feb 2025 10:38:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you look at adding native init method instead? This could be called from the System.loadLibraray and avoid introduce a side effect of startThreads initialising GetCreatedJavaVMs.

Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup into JNI_OnLoad.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2644030507

From lmesnik at openjdk.org  Fri Feb  7 21:20:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 7 Feb 2025 21:20:41 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
Message-ID: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>

The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

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

Commit messages:
 - 8346050: Update BuildTestLib.gmk to build whole testlibrary

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

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

From honkar at openjdk.org  Fri Feb  7 22:48:09 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 22:48:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
 <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
Message-ID: <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>

On Fri, 7 Feb 2025 14:11:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> What tests have you run?
>
>> What tests have you run?
> 
> Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
> However I think I have to run some more manual tests on client  like  setups.
> 
> Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.

@MBaesken 

> However I think I have to run some more manual tests on client like setups.

SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests to check if the tests work fine with the fix. 

What are we specifically looking for in the tests with this fix?  No degradation in test startup or execution time?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2644266008

From jiangli at openjdk.org  Fri Feb  7 23:58:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 23:58:09 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <G4v0uyHkXMp9NzjNuumLVxu0BVaDjw4l7Cfl07mZdlU=.5479724a-9254-40c7-b060-ef4a8b5933b8@github.com>
Message-ID: <CK3SLPe49AcZI8sIv09GaMLYoreVI4qUKf-bbEtwVYw=.78d76848-088e-40ff-9085-e34a31b7faa7@github.com>

On Tue, 4 Feb 2025 19:04:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
>
>> @jianglizhou I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a static JDK we have to rewrite the test to perform a dynamic lookup!
> 
> A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM).
> 
> So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.

@AlanBateman I created https://github.com/openjdk/jdk/pull/23528 for the VMProps change. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2644342524

From erikj at openjdk.org  Sat Feb  8 00:11:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Sat, 8 Feb 2025 00:11:14 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
In-Reply-To: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
Message-ID: <U6vym4GDRAbbO-eHbIdiJWesEV7k08KJraHXY8OYWok=.84e77482-ecbf-425a-b203-269474040e0e@github.com>

On Fri, 7 Feb 2025 21:15:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

make/test/BuildTestLib.gmk line 61:

> 59: 
> 60: ifeq ($(call isTargetOs, linux), false)
> 61:     EXCLUDE_DIRS := jdk/test/lib/containers

Suggestion:

  EXCLUDE_DIRS := jdk/test/lib/containers

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1947340369

From prr at openjdk.org  Sat Feb  8 04:13:14 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 8 Feb 2025 04:13:14 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.

I think what we are looking for in testing is no functional regression plus minimal perf impact on startup.
But I don't think any of our jtreg tests are set up to measure the perf so can only ensure the functional.
It would be good to check that as mentioned.
And I don't remember anyone ever testing perf of splash since the point of splash is to mask the much bigger hit of booting up the JVM .. so I doubt we'll be able to test it today.
But I'll make a note to self to ask the people who do perf testing to think about this, or perhaps tell me "gosh Phil, we've been testing that forever, didn't you know" ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2644488159

From lmesnik at openjdk.org  Sat Feb  8 05:01:03 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 8 Feb 2025 05:01:03 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v2]
In-Reply-To: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
Message-ID: <p7QKZYsfKaf3Jg_1NTvWHky7tzkZfIyO_0-mbDXBIag=.8e56af38-82c9-41f1-8f04-a50523f3e2b2@github.com>

> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

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

  Update make/test/BuildTestLib.gmk
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23525/files
  - new: https://git.openjdk.org/jdk/pull/23525/files/8afdb494..fad9ad2d

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

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

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

From alanb at openjdk.org  Sat Feb  8 09:32:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Feb 2025 09:32:10 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
Message-ID: <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>

On Fri, 7 Feb 2025 20:10:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JNI_GetCreatedJavaVMs lookup into JNI_OnLoad, to address AlanBateman's suggestion.

test/jdk/java/lang/Thread/jni/AttachCurrentThread/libExplicitAttach.c line 57:

> 55:         return JNI_ERR;
> 56:     }
> 57:     return JNI_VERSION_1_8;

Is the JavaVM param passed to JNI_OnLoad usable in static builds? If so then this just needs to be saved, no need to use GetCreatedJavaVMs, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23500#discussion_r1947551019

From mbaesken at openjdk.org  Sun Feb  9 14:44:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 9 Feb 2025 14:44:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
Message-ID: <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>

On Sat, 8 Feb 2025 04:10:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.

Please note that AIX has the debuginfo in the same binary (.so file), unlike e.g. Linux.
If you look at the size reduction of the debuginfo files on Linux, this goes down from 1.7M -> 1.4M  on Linux x86_64 so it is also quite a good reduction.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2646332828

From mbaesken at openjdk.org  Sun Feb  9 14:44:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 9 Feb 2025 14:44:10 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
 <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>
Message-ID: <CmpH9mrxrYHT5eh7RO79Sfd5sG5r1MYenC1z9MRJJFI=.bd878afe-a164-4108-bec1-fbe7d4019ee2@github.com>

On Sun, 9 Feb 2025 14:39:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.
>> 
>> I think what we are looking for in testing is no functional regression plus minimal perf impact on startup.
>> But I don't think any of our jtreg tests are set up to measure the perf so can only ensure the functional.
>> It would be good to check that as mentioned.
>> And I don't remember anyone ever testing perf of splash since the point of splash is to mask the much bigger hit of booting up the JVM .. so I doubt we'll be able to test it today.
>> But I'll make a note to self to ask the people who do perf testing to think about this, or perhaps tell me "gosh Phil, we've been testing that forever, didn't you know" ?
>
>> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.
> 
> Please note that AIX has the debuginfo in the same binary (.so file), unlike e.g. Linux.
> If you look at the size reduction of the debuginfo files on Linux, this goes down from 1.7M -> 1.4M  on Linux x86_64 so it is also quite a good reduction.

> @MBaesken
> 
> > However I think I have to run some more manual tests on client like setups.
> 
> SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests on your behalf to check if the tests work fine with the fix.
> 
> What are we specifically looking for in the tests with this fix? No degradation in test startup and execution time?

If you find the time to run those, would be great. And yes a noticeable degradation would be important to know.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2646333958

From jiangli at openjdk.org  Mon Feb 10 03:53:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 03:53:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
 <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>
Message-ID: <0eVzIjugTG80YcdBQ46poOhNtkPHHpmV4QhvQU0znZc=.7a325e78-11ed-42ae-bee6-7f94968c01c3@github.com>

On Sat, 8 Feb 2025 09:29:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is the JavaVM param passed to JNI_OnLoad usable in static builds? If so then this just needs to be saved, no need to use GetCreatedJavaVMs, right?

Yes, on static JDK, `JNI_OnLoad`'s `JavaVM *` argument behaves the same as on regular JDK. It points to the current VM. IIUC, `libExplicitAttach.c` does not appear to explicitly test `JNI_GetCreatedJavaVMs`, but only calls it to retrieve the VM. Removing the `JNI_GetCreatedJavaVMs` call can result a cleaner fix. Thanks for pointing that out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23500#discussion_r1948363497

From jiangli at openjdk.org  Mon Feb 10 03:56:42 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 03:56:42 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v3]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <C9OCiz0yBcm7d-Q8sXlTfeB1GDnJ7Q0CEVb0NbNfNiw=.e5f126a7-35c5-488d-bec4-72b9be53ebee@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  - Stash `JavaVM *` argument from `JNI_OnLoad`. Remove `JNI_GetCreatedJavaVMs`. Thanks AlanBateman for noticing that.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/4ee170d2..1da4da96

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

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

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

From alanb at openjdk.org  Mon Feb 10 07:28:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 07:28:10 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
 <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>
Message-ID: <OYwib11w03AEAzDGZikCoKJ9iU2dtWEEYs75Un_XaYQ=.1c3a64be-2102-4567-990c-027357100933@github.com>

On Fri, 7 Feb 2025 20:10:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup into JNI_OnLoad.

Good, this is much better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2647141990

From alanb at openjdk.org  Mon Feb 10 07:28:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 07:28:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

Can you bump the copyright header date on libExplicitAttach.c before you integrate.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2604875066

From dholmes at openjdk.org  Mon Feb 10 10:16:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Feb 2025 10:16:15 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
Message-ID: <86_No6nGwjBtEc2mxOHUkN71Hjf8qp5ama5fx1obJE4=.dd438732-a372-4863-899a-f8317fd5476d@github.com>

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

Okay - approved.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23431#pullrequestreview-2605294024

From dholmes at openjdk.org  Mon Feb 10 10:25:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Feb 2025 10:25:11 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <ue30YRpX05j5Vck8GnhKUh1k_7wcnBFb-b6c9yRZDQo=.1287477c-818e-4fb1-b932-d5afdf0e481a@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

This seems a nice simplification to me too.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2605315239

From ihse at openjdk.org  Mon Feb 10 16:23:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Feb 2025 16:23:37 GMT
Subject: RFR: 8349515: [REDO] Framework for tracing makefile inclusion and
 parsing
Message-ID: <JnMtGuh4_2goIW4arqmRPnnuaEoaDpnc3zYvlSOhasQ=.830d3a4b-7579-4738-b2b5-f6e82d21f690@github.com>

Re-do of [JDK-8348190](https://bugs.openjdk.org/browse/JDK-8348190) Framework for tracing makefile inclusion and parsing.

This should be essentially identical to JDK-8348190; the fixes were in closed Oracle source. My apologizes for all this mess, and that it spilled out in the open JDK instead of being resolved just internally at Oracle. ?

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

Commit messages:
 - Checking for top-level file inclusion is not really dependent on makelevel
 - 8349515: [REDO] Framework for tracing makefile inclusion and parsing

Changes: https://git.openjdk.org/jdk/pull/23494/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349515
  Stats: 2699 lines in 273 files changed: 1645 ins; 485 del; 569 mod
  Patch: https://git.openjdk.org/jdk/pull/23494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23494/head:pull/23494

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

From bpb at openjdk.org  Mon Feb 10 17:18:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Feb 2025 17:18:21 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <_zxZyGe0-1D_LWJyhrJqYu3e_RLBHJ0si_SRuptCkSE=.435a91e7-277b-4187-b804-692aba507dd2@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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 11 commits:
> 
>  - 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
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2648719746

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v5]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/317d2315..98d1dea8

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

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

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

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
 <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>
Message-ID: <MdSURK8QBOFrG-TglUh6uReGpe_ES4teDQnV_zMvvvI=.cc4d452c-c7eb-42a0-ac1c-470134c7bbe3@github.com>

On Mon, 10 Feb 2025 07:26:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you bump the copyright header date on libExplicitAttach.c before you integrate.

Done.

@AlanBateman @dholmes-ora Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2648775523

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <L7nT3jgGYzuXEC7ay01DDOcAZbIMXBV81BCURMf96Yk=.cdc5f721-a69d-44aa-9ff0-a137bfefe404@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

Looks like the copyright header update required the PR to be reviewed again before integration. Could you review again? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2648779004

From jiangli at openjdk.org  Mon Feb 10 18:08:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 18:08:15 GMT
Subject: RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
 <WCOQRkIZ_fPfl72TSm-CXj_9DglroDxI2UofF_O5wz0=.5d47b2bd-2860-479f-ab38-69255c2a94cd@github.com>
 <o3IFur_F8vhD_UmaIF-sGJNvZHu20YikIVLpupw0IoE=.6de6840a-1582-4f37-9782-e7cf3f703b8e@github.com>
Message-ID: <8c16ZISEufaQY3veBo1CAW-bZbTHlWaiJe9Fcw7KMOQ=.9f5abed1-c1ec-44e9-b052-468014d0b436@github.com>

On Wed, 5 Feb 2025 01:12:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
>
>> Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.
> 
> Is there any other example? Presuming the existence of dynamic linked libraries is pretty standard.

Thanks, @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2648837104

From jiangli at openjdk.org  Mon Feb 10 18:08:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 18:08:16 GMT
Subject: Integrated: 8349178: runtime/jni/atExit/TestAtExit.java should be
 supported on static JDK
In-Reply-To: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
References: <YdYOf9_i6SPxNwe2-E_IkuhkjJe6bguik3VB1fPmEdY=.6b09d536-7e79-483f-b128-0a148a8550c4@github.com>
Message-ID: <spm2ePGSZTlfcQioRZXrGv7dLII_5VnN5GbdCsu3EzQ=.c66be1b9-74b0-4398-800c-8885c5f083fd@github.com>

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

This pull request has now been integrated.

Changeset: 84b32cb6
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84b32cb61c3e04189eb811fa052747e21ca6aff1
Stats:     56 lines in 2 files changed: 52 ins; 1 del; 3 mod

8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

Reviewed-by: dholmes

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

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

From alanb at openjdk.org  Mon Feb 10 19:04:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 19:04:11 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v5]
In-Reply-To: <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>
Message-ID: <T2VCnKv5za7quw54eCsGWOJSBuGieRiWsK7NSO3nVvY=.449f656c-5b0e-47a5-a980-1c1065a0b111@github.com>

On Mon, 10 Feb 2025 17:41:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2606882163

From prr at openjdk.org  Mon Feb 10 19:40:15 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Feb 2025 19:40:15 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <aQRYaau4QLQAaLP94AeOYPASg_9kKXp01ixB3b8cPD0=.5b9c27ae-7f59-4aaf-95ac-ff584bb1ebc5@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

Looks OK to me. But Harshitha is going to do a bit of testing, so wait for her.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2606975133

From jiangli at openjdk.org  Mon Feb 10 20:18:43 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 20:18:43 GMT
Subject: RFR: 8349752: Tier1 build failure caused by JDK-8349178
Message-ID: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>

Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target.

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

Commit messages:
 - Fix lib name.
 - Add `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := -ldl` for linux target.

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

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

From jiangli at openjdk.org  Mon Feb 10 20:22:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 20:22:15 GMT
Subject: Integrated: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <WLkAvyKZ3ca5vBWdBccxB5lYNpGPLXFqFRPhfG5JWsY=.0e437e6b-f62d-485e-b914-c92349b21f1e@github.com>

On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

This pull request has now been integrated.

Changeset: 527489c0
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/527489c06d827f5d08a8053bedcd26db4608c9f0
Stats:     18 lines in 2 files changed: 7 ins; 10 del; 1 mod

8349284: Make libExplicitAttach work on static JDK

Reviewed-by: alanb, dholmes

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

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

From dholmes at openjdk.org  Mon Feb 10 20:48:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Feb 2025 20:48:16 GMT
Subject: RFR: 8349752: Tier1 build failure caused by JDK-8349178
In-Reply-To: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
References: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
Message-ID: <jD0Rkvr75uDx16EasvGYEe-mbq8XZx3yWyukATjFImg=.90ef7014-fc17-4a45-a027-aafcf4a9e5ec@github.com>

On Mon, 10 Feb 2025 20:13:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target.

This matches other tests that use dlsym. I don't understand why this wasn't caught in pre-integration testing. Please integrate ASAP. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23544#pullrequestreview-2607129283

From jiangli at openjdk.org  Mon Feb 10 20:55:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 20:55:15 GMT
Subject: Integrated: 8349752: Tier1 build failure caused by JDK-8349178
In-Reply-To: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
References: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
Message-ID: <RAgbx2Sk2M4XiGsZi-n5zqKkR05s3LHn9R1Bb3NmKkQ=.d0a4162a-8b7d-4e82-a8a7-40e0ac4170e0@github.com>

On Mon, 10 Feb 2025 20:13:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target.

This pull request has now been integrated.

Changeset: df654a9f
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df654a9f581ed9e43e3f329bb01204ac2fb9f509
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8349752: Tier1 build failure caused by JDK-8349178

Reviewed-by: dholmes

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

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

From jiangli at openjdk.org  Mon Feb 10 20:55:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 20:55:15 GMT
Subject: RFR: 8349752: Tier1 build failure caused by JDK-8349178
In-Reply-To: <jD0Rkvr75uDx16EasvGYEe-mbq8XZx3yWyukATjFImg=.90ef7014-fc17-4a45-a027-aafcf4a9e5ec@github.com>
References: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
 <jD0Rkvr75uDx16EasvGYEe-mbq8XZx3yWyukATjFImg=.90ef7014-fc17-4a45-a027-aafcf4a9e5ec@github.com>
Message-ID: <4MRZFrGP2HnnsBKmt2SLC0Tt7i4SC-ANMrdM5WhgMsA=.2074225e-efff-4a19-842f-a55c1f54b359@github.com>

On Mon, 10 Feb 2025 20:45:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This matches other tests that use dlsym. I don't understand why this wasn't caught in pre-integration testing. Please integrate ASAP. Thanks.

Yeah, I have the same question... I'm integrating now. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23544#issuecomment-2649208848

From ihse at openjdk.org  Mon Feb 10 21:18:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Feb 2025 21:18:10 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v2]
In-Reply-To: <p7QKZYsfKaf3Jg_1NTvWHky7tzkZfIyO_0-mbDXBIag=.8e56af38-82c9-41f1-8f04-a50523f3e2b2@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <p7QKZYsfKaf3Jg_1NTvWHky7tzkZfIyO_0-mbDXBIag=.8e56af38-82c9-41f1-8f04-a50523f3e2b2@github.com>
Message-ID: <bXkECrYUuCmHvjqd5DEjKYZ8DQODHbUEUzUTAJ_bnD8=.8abb35ed-8174-4c60-915c-050a44dce946@github.com>

On Sat, 8 Feb 2025 05:01:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/test/BuildTestLib.gmk
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

make/test/BuildTestLib.gmk line 61:

> 59: 
> 60: ifeq ($(call isTargetOs, linux), false)
> 61:   EXCLUDE_DIRS := jdk/test/lib/containers

Please call this either just "EXCLUDES", or even better `BUILD_TEST_LIB_JAR_EXCLUDES` (to conform with existing practice). Changing the name like this sounds like it is going to be assigned to another argument; we have various ways to exclude files and `EXCLUDES` is only one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1949903110

From erikj at openjdk.org  Mon Feb 10 21:26:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Feb 2025 21:26:11 GMT
Subject: RFR: 8349515: [REDO] Framework for tracing makefile inclusion and
 parsing
In-Reply-To: <JnMtGuh4_2goIW4arqmRPnnuaEoaDpnc3zYvlSOhasQ=.830d3a4b-7579-4738-b2b5-f6e82d21f690@github.com>
References: <JnMtGuh4_2goIW4arqmRPnnuaEoaDpnc3zYvlSOhasQ=.830d3a4b-7579-4738-b2b5-f6e82d21f690@github.com>
Message-ID: <SIX2eKkPsEr__IRyM6Axga1mJb0GwxGVKlzuA3megxc=.5576d53f-5e88-4eae-94ca-b3ad05942033@github.com>

On Thu, 6 Feb 2025 14:01:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Re-do of [JDK-8348190](https://bugs.openjdk.org/browse/JDK-8348190) Framework for tracing makefile inclusion and parsing.
> 
> This should be essentially identical to JDK-8348190; the fixes were in closed Oracle source. My apologizes for all this mess, and that it spilled out in the open JDK instead of being resolved just internally at Oracle. ?

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23494#pullrequestreview-2607202982

From dholmes at openjdk.org  Tue Feb 11 06:29:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Feb 2025 06:29:17 GMT
Subject: RFR: 8349752: Tier1 build failure caused by JDK-8349178
In-Reply-To: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
References: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
Message-ID: <qB5smzp3DYPG2-_3UeviafLa5U4qgCTl0-v1-DRU5ZM=.dddb6781-3426-4470-90bd-2b5f3e9da5a3@github.com>

On Mon, 10 Feb 2025 20:13:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Add `BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libatExit += -ldl` for linux target.

I am at a loss to understand how the initial change built and tested with no problem even though `-ldl` was missing. Maybe there is some way to set a default set of libraries to check and the toolchain include libdl.so in that. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/23544#issuecomment-2649903255

From djelinski at openjdk.org  Tue Feb 11 09:09:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Feb 2025 09:09:43 GMT
Subject: RFR: 8349781: make test TEST=gtest fails on WSL
Message-ID: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>

`make test TEST=gtest` fails to run gtest on WSL. This is because we're looking for a nonexistent file `gtestLauncher`; on Windows the file is named `gtestLauncher.exe`.

This PR adds `$EXECUTABLE_SUFFIX` to the executable path, similar to what [GtestImage.gmk already does](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/hotspot/test/GtestImage.gmk#L37).

I verified that with the proposed change, `make test TEST=gtest` works correctly both on WSL and on Cygwin. Other platforms are unaffected, because EXECUTABLE_SUFFIX is [empty on all non-Windows platforms](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/autoconf/toolchain.m4#L188).

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

Commit messages:
 - Add exe suffix to gtestLauncher search path

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

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

From ihse at openjdk.org  Tue Feb 11 10:58:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Feb 2025 10:58:18 GMT
Subject: Integrated: 8349515: [REDO] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <JnMtGuh4_2goIW4arqmRPnnuaEoaDpnc3zYvlSOhasQ=.830d3a4b-7579-4738-b2b5-f6e82d21f690@github.com>
References: <JnMtGuh4_2goIW4arqmRPnnuaEoaDpnc3zYvlSOhasQ=.830d3a4b-7579-4738-b2b5-f6e82d21f690@github.com>
Message-ID: <eQHeV-BNa9wcuOl6dun5l5iEAFp08UKZkrYpMfWTflU=.0d50a032-36f0-4f37-b839-e215d14fa9cb@github.com>

On Thu, 6 Feb 2025 14:01:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Re-do of [JDK-8348190](https://bugs.openjdk.org/browse/JDK-8348190) Framework for tracing makefile inclusion and parsing.
> 
> This should be essentially identical to JDK-8348190; the fixes were in closed Oracle source. My apologizes for all this mess, and that it spilled out in the open JDK instead of being resolved just internally at Oracle. ?

This pull request has now been integrated.

Changeset: 964dd18f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/964dd18fd2ba998e5c1efed48e15e516b0c22b19
Stats:     2699 lines in 273 files changed: 1645 ins; 485 del; 569 mod

8349515: [REDO] Framework for tracing makefile inclusion and parsing

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Tue Feb 11 13:44:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Feb 2025 13:44:09 GMT
Subject: RFR: 8349781: make test TEST=gtest fails on WSL
In-Reply-To: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
References: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
Message-ID: <N7iq1W85Joqsqv2FqQyd7Tq5vxaN-Z89RdrU4flB1Zg=.37813ae6-82ee-4337-a925-de0f71713d71@github.com>

On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `make test TEST=gtest` fails to run gtest on WSL. This is because we're looking for a nonexistent file `gtestLauncher`; on Windows the file is named `gtestLauncher.exe`.
> 
> This PR adds `$EXECUTABLE_SUFFIX` to the executable path, similar to what [GtestImage.gmk already does](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/hotspot/test/GtestImage.gmk#L37).
> 
> I verified that with the proposed change, `make test TEST=gtest` works correctly both on WSL and on Cygwin. Other platforms are unaffected, because EXECUTABLE_SUFFIX is [empty on all non-Windows platforms](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/autoconf/toolchain.m4#L188).

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23555#pullrequestreview-2608790106

From cstein at openjdk.org  Tue Feb 11 14:53:09 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Feb 2025 14:53:09 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1
Message-ID: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>

Please review the change to update to using jtreg 7.5.1.

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

_Testing..._ tier 1 ? tier 8

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

Commit messages:
 - Use tagged jtreg version
 - Prepare to use jtreg 7.5.1

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

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

From mbaesken at openjdk.org  Tue Feb 11 16:01:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Feb 2025 16:01:45 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
Message-ID: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>

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 .

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

Commit messages:
 - JDK-8349638

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

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

From mbaesken at openjdk.org  Tue Feb 11 16:16:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Feb 2025 16:16:10 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: <OXCRbpvs0LRb0-1nM3XPf9aIN6InJ1MxebrYdD53Ivg=.9e67bcae-6720-43e6-8bf6-6dfe8a50da9d@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 .

Build time  (JOBS=1,  on Linux x86_64) of the project is pretty similar with LOW and SIZE.

      SIZE      LOW
real  14,7     15,4
usr   8.0       8,4
sys   1.9       2,0

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

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

From jiangli at openjdk.org  Tue Feb 11 16:23:19 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Feb 2025 16:23:19 GMT
Subject: RFR: 8349752: Tier1 build failure caused by JDK-8349178
In-Reply-To: <qB5smzp3DYPG2-_3UeviafLa5U4qgCTl0-v1-DRU5ZM=.dddb6781-3426-4470-90bd-2b5f3e9da5a3@github.com>
References: <3DzADzw0HNWC7bGftcaRaHMKvZsHwE0HwfBc1hNjXCw=.c8f32827-1138-4d18-a7d5-487db9cde352@github.com>
 <qB5smzp3DYPG2-_3UeviafLa5U4qgCTl0-v1-DRU5ZM=.dddb6781-3426-4470-90bd-2b5f3e9da5a3@github.com>
Message-ID: <Zzp-Lcxds6piwVxhJ3jPFdwVie6cMQ3yNhK7BVhfBA0=.41a9df1c-ceb4-4e7f-8dd6-b00d8dfce7b8@github.com>

On Tue, 11 Feb 2025 06:26:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I am at a loss to understand how the initial change built and tested with no problem even though `-ldl` was missing. Maybe there is some way to set a default set of libraries to check and the toolchain include libdl.so in that. ??

@dholmes-ora I just added a comment at https://bugs.openjdk.org/browse/JDK-8349752?focusedId=14751058&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14751058, duplicating below:

I had to refresh my memory on this (I now recall that I've run into related issue in the past), but I know the reason now why the build is successfully even without `-ldl`. `--allow-shlib-undefined` is the default on gnu linker. I linked "binutils/docs-2.18/ld/" below. Is `--no-allow-shlib-undefined` or `--no-undefined` specified for the linker in the closed test environment?

https://sourceware.org/binutils/docs-2.18/ld/Options.html#:~:text=The%20reason%20that%20%2D%2Dallow,be%20resolvable%20at%20load%20time:

> --allow-shlib-undefined
> --no-allow-shlib-undefined
>
> Allows (the default) or disallows undefined symbols in shared libraries. This switch is similar to --no-undefined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled.
> The reason that --allow-shlib-undefined is the default is that the shared library being specified at link time may not be the same as the one that is available at load time, so the symbols might actually be resolvable at load time. Plus there are some systems, (eg BeOS) where undefined symbols in shared libraries is normal. (The kernel patches them at load time to select which function is most appropriate for the current architecture. This is used for example to dynamically select an appropriate memset function). Apparently it is also normal for HPPA shared libraries to have undefined symbols.

Following is the `gcc` & `ld` from the github build machine (https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36617644281). The linker is `2.38 [GNU ld (GNU Binutils for Ubuntu) 2.38]`.


configure: Using gcc C compiler version 10.5.0 [gcc (Ubuntu 10.5.0-1ubuntu1~22.04) 10.5.0]
...
checking resolved symbolic links for CXX... /usr/bin/x86_64-linux-gnu-g++-10
configure: Using gcc C++ compiler version 10.5.0 [g++ (Ubuntu 10.5.0-1ubuntu1~22.04) 10.5.0]
...
configure: Using gcc linker version 2.38 [GNU ld (GNU Binutils for Ubuntu) 2.38]
configure: comparing linker version to minimum version 2.25

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

PR Comment: https://git.openjdk.org/jdk/pull/23544#issuecomment-2651314171

From lmesnik at openjdk.org  Tue Feb 11 17:10:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Feb 2025 17:10:37 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v3]
In-Reply-To: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
Message-ID: <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>

> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050
 - renamed excludes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23525/files
  - new: https://git.openjdk.org/jdk/pull/23525/files/fad9ad2d..4813daed

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

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

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

From erikj at openjdk.org  Tue Feb 11 17:25:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Feb 2025 17:25:12 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1
In-Reply-To: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
Message-ID: <C-60D-6hfhYgiKG8Zu6WnkBGVI1mcS2kqQzW6o-giwg=.12a215c5-f815-45a5-a16b-d2abfd9573f4@github.com>

On Thu, 29 Aug 2024 11:26:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2609473912

From jwaters at openjdk.org  Tue Feb 11 17:33:16 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Feb 2025 17:33:16 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: <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@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 .

Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

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

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

From cjplummer at openjdk.org  Tue Feb 11 19:04:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 19:04:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
Message-ID: <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>

On Tue, 11 Feb 2025 17:30:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

There's no C++ code in libjdwp

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

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

From cjplummer at openjdk.org  Tue Feb 11 19:04:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 19:04:10 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: <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@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'm not too familiar with optimization choices in the build system, but it seems libjdwp should be built optimized in the same manner as libjvm.

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

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

From honkar at openjdk.org  Tue Feb 11 20:26:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Feb 2025 20:26:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <kwZOkYS-2xkZYVVGhKwwaTOjeG-tROXU3LhikLf1gjI=.33c2d50e-0e17-4cad-8059-786694d58e23@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

SplashScreen tests work as expected on all platforms. No regressions observed.

With optimization=SIZE, libsplashscreen image file sizes are less on linux and macOS.
On the contrary, the .dll files on Windows were slightly bigger with opt=SIZE than with opt=LOW for me (Win 11 x86-64).  Details below.


macOS
--------
408K Feb 10 14:59 libsplashscreen.dylib
96B Feb 10 15:00 libsplashscreen.dylib.dSYM

344K Feb 11 10:38 libsplashscreen.dylib
96B Feb 11 10:39 libsplashscreen.dylib.dSYM

Linux
-----
1.7M Feb 10 16:39 libsplashscreen.debuginfo
364K Feb 10 16:39 libsplashscreen.so

1.4M Feb 11 10:58 libsplashscreen.debuginfo
293K Feb 11 10:58 libsplashscreen.so

Windows
----------
201K Feb  7 15:37 splashscreen.dll
177K Feb  7 15:37 splashscreen.dll.map
1.6M Feb  7 15:37 splashscreen.dll.pdb

547K Feb 11 11:31 splashscreen.dll
281K Feb 11 11:31 splashscreen.dll.map
1.7M Feb 11 11:31 splashscreen.dll.pdb

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

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2609945290

From jiangli at openjdk.org  Tue Feb 11 21:41:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Feb 2025 21:41:15 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
Message-ID: <HpDK2XEWNhDPXPG_vMOi4HrGsjnq_BCO4W3WE5mgZxw=.e1d20001-25a6-46ca-946b-c1c6e9b9a460@github.com>

On Thu, 6 Feb 2025 17:01:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?

> @shipilev Thanks for looking into this.
> 
> > What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?
> 
> Currently, the main difference is avoiding building `static-libs-bundles` completely in `build-linux-static.yml`, since that's not needed for the testing purpose with `static-jdk-image`. In `build-linux.yml`, there is the following logic that skips building `static-libs-bundles` but for `fastdebug` build only. I actually initially started using `build-linux.yml` for the static build job, but later added `build-linux-static.yml` when I was looking for a cleaner way to skipping building `static-libs-bundles`.
> 
> ```
>           # Only build static-libs-bundles for release builds.
>           # For debug builds, building static-libs often exceeds disk space.
>           STATIC_LIBS: ${{ matrix.debug-level == 'release' && 'static-libs-bundles' }}
> ```

@shipilev Can you help review/approve the change, if no other questions?

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2652125359

From jiangli at openjdk.org  Wed Feb 12 00:07:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 00:07:24 GMT
Subject: RFR: 8349859: Support static JDK in libfontmanager/freetypeScaler.c
Message-ID: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>

Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 

According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.

I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

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

Commit messages:
 - Check if FT_Property_Set can be found from the executable if running on static JDK, before trying to load libfreetype.so.

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

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

From jiangli at openjdk.org  Wed Feb 12 03:05:44 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 03:05:44 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency from
 jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
Message-ID: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>

Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

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

Commit messages:
 - Remove libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel.

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

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

From prr at openjdk.org  Wed Feb 12 05:10:10 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 05:10:10 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 303:

> 301: #else
> 302: 
> 303:     if (JVM_IsStaticallyLinked()) {

These kinds of checks on behalf of a statically linked build are quite intrusive.
Perhaps there is no alternative, but still.
SFAIK, at this time, no one is under any obligation to test this works, or to know how not to break it.
So I will approve with those caveats.

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

PR Review: https://git.openjdk.org/jdk/pull/23574#pullrequestreview-2610823880
PR Review Comment: https://git.openjdk.org/jdk/pull/23574#discussion_r1951984223

From alanb at openjdk.org  Wed Feb 12 07:03:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 07:03:09 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

@bplb You may have to double check that this works for us.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2652824313

From mbaesken at openjdk.org  Wed Feb 12 07:34:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:34:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
Message-ID: <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>

On Tue, 11 Feb 2025 19:01:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not too familiar with optimization choices in the build system, but it seems libjdwp should be built optimized in the same manner as libjvm.

LIBJVM is built with optimization level  HIGHEST_JVM (seems this is -O3 with gcc/clang) by default , but there are configure-options to switch, if desired, to SIZE or to lto-optimization for libjvm 
https://github.com/openjdk/jdk/blob/adda12b724ec5fb890ef18ae21f0b5985ececfea/make/hotspot/lib/CompileJvm.gmk#L141

LIBJDWP is currently built with optimization level LOW.

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

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

From mbaesken at openjdk.org  Wed Feb 12 07:34:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:34:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
Message-ID: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>

On Tue, 11 Feb 2025 19:00:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

Thanks for the heads up. Most  JDK libs are C , only very few contain C++ (I think harfbuzz is an example that comes to mind).   As pointed out,  libjdwp is not among the libs with C++.

Do you have an example of a bug caused by the issue you mention (and is this already documented in the JBS somewhere) ?

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

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

From mbaesken at openjdk.org  Wed Feb 12 07:45:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:45:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
Message-ID: <pKsn-Ek55gNwweWCB4N1N6J58coRVlU8B4hZRsjb0UA=.86b33954-de48-47fe-b227-014f53587787@github.com>

On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

Maybe per lib, additionally to the currently offered optimization options LOW, SIZE, HIGH etc  (the ones we currently have now) ?
But this is for another issue/PR .

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

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

From cjplummer at openjdk.org  Wed Feb 12 08:08:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 08:08:23 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
 <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
Message-ID: <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>

On Wed, 12 Feb 2025 07:29:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> LIBJDWP is currently built with optimization level LOW.

Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a reason for focusing on footprint here? What is the footprint different between HIGH and LOW?

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

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

From mbaesken at openjdk.org  Wed Feb 12 08:33:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:33:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
 <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
 <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>
Message-ID: <h2K9AldctVsSyxQT0zGKScyK8wR5XmGoS5lkihI2tsw=.4fb04ed5-d7a3-480b-84f4-e98ac339068e@github.com>

On Wed, 12 Feb 2025 08:05:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > LIBJDWP is currently built with optimization level LOW.
> 
> Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a reason for focusing on footprint here? What is the footprint different between HIGH and LOW?

I tested various jdk native libs that are currently compiled with LOW , how they do with SIZE.
For some of those libs the size reduction is not very good, but for some it is 10 or 20 % .
So I focused on those that are compiled currently with LOW and might do better with SIZE.

I can test with HIGH instead of LOW, but I have for those JDK native libs usually no benchmarks showing any improvements,
For SIZE it is possible to show an improvement (in size) if there is one (or the other way around, for some libs it is easy to show that they do pretty much the same with SIZE and LOW).

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

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

From jwaters at openjdk.org  Wed Feb 12 08:36:09 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Feb 2025 08:36:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
Message-ID: <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>

On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Do you have an example of a bug caused by the issue you mention (and is this already documented in the JBS somewhere) ?

I don't believe this is documented anywhere in the issue tracker, I'll do so in a moment. The bug is an Internal Compiler Error, gcc crashes when that flag is on (And LTO seems to raise the likelihood of gcc crashing). It was supposedly fixed, but the crash still happens even with newer gcc so the fix doesn't seem to have worked

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

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

From mbaesken at openjdk.org  Wed Feb 12 08:45:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:45:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
 <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>
Message-ID: <r5UAbj1yl4cbJMHujCB9mDM1qwMLCfNfvGAM1qzWvl0=.2d129716-35c8-4c89-9c17-eff52e1fb256@github.com>

On Wed, 12 Feb 2025 08:34:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The bug is an Internal Compiler Error, gcc crashes when that flag is on (And LTO seems to raise the likelihood of gcc crashing).

Thanks for the details. I never saw this when setting opt-size AND lto/linktime-opt for libjvm; maybe my gcc 11.3 is good and does not show this.   But in case it shows up it is at least a bug that is easily visible because the build fails.

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

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

From mbaesken at openjdk.org  Wed Feb 12 08:58:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:58:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
 <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
 <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>
Message-ID: <Hr1Xf9dyrLak-GvqGpT6QKN4Nn-UC_F02tV4v_RowIU=.f0fa3277-f876-4528-8692-4fc72b2e375f@github.com>

On Fri, 7 Feb 2025 22:45:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> What tests have you run?
>> 
>> Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
>> However I think I have to run some more manual tests on client  like  setups.
>> 
>> Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.
>
> @MBaesken 
> 
>> However I think I have to run some more manual tests on client like setups.
> 
> SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests on your behalf to check if the tests work fine with the fix. 
> 
> What are we specifically looking for in the tests with this fix?  No degradation in test startup and execution time?

@honkar-jdk do you have the latest/newest jdk head, especially this change is important 
8349214: Improve size optimization flags for MSVC builds
https://github.com/openjdk/jdk/commit/40603a5bf039eef03c157bfc49ac8ea2229a94de

Before the SIZE opt flags for MSVC were bad.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2653033507

From mbaesken at openjdk.org  Wed Feb 12 09:02:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 09:02:15 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: <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@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 .
> 

This is what I get with HIGH ,  on Linux x86_64 (gcc 11.3 used)

du -sh images/jdk/lib/libjdwp.*
2.0M	images/jdk/lib/libjdwp.debuginfo
316K	images/jdk/lib/libjdwp.so

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

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

From djelinski at openjdk.org  Wed Feb 12 09:07:13 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Feb 2025 09:07:13 GMT
Subject: RFR: 8349781: make test TEST=gtest fails on WSL
In-Reply-To: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
References: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
Message-ID: <ydd6_yCNBVnA3YbpoDxxvUCPVBSq7p-VPc5UG3SAxaY=.c916c3c9-d017-4a4e-bcde-7deda1d690ca@github.com>

On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `make test TEST=gtest` fails to run gtest on WSL. This is because we're looking for a nonexistent file `gtestLauncher`; on Windows the file is named `gtestLauncher.exe`.
> 
> This PR adds `$EXECUTABLE_SUFFIX` to the executable path, similar to what [GtestImage.gmk already does](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/hotspot/test/GtestImage.gmk#L37).
> 
> I verified that with the proposed change, `make test TEST=gtest` works correctly both on WSL and on Cygwin. Other platforms are unaffected, because EXECUTABLE_SUFFIX is [empty on all non-Windows platforms](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/autoconf/toolchain.m4#L188).

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23555#issuecomment-2653056144

From djelinski at openjdk.org  Wed Feb 12 09:07:13 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Feb 2025 09:07:13 GMT
Subject: Integrated: 8349781: make test TEST=gtest fails on WSL
In-Reply-To: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
References: <90wtFC3oIZSttqkMoDHZwWzJO0_bh-dIHq8f0O2WMU8=.5dadd0f0-57b8-406e-81ba-63277e0ffeb2@github.com>
Message-ID: <f7UJ25oX5iVoCifSZo__xjhpmLJhg2z1QY6_SuEd6X0=.70f23515-38c4-4805-a0cb-a98681fc0221@github.com>

On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> `make test TEST=gtest` fails to run gtest on WSL. This is because we're looking for a nonexistent file `gtestLauncher`; on Windows the file is named `gtestLauncher.exe`.
> 
> This PR adds `$EXECUTABLE_SUFFIX` to the executable path, similar to what [GtestImage.gmk already does](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/hotspot/test/GtestImage.gmk#L37).
> 
> I verified that with the proposed change, `make test TEST=gtest` works correctly both on WSL and on Cygwin. Other platforms are unaffected, because EXECUTABLE_SUFFIX is [empty on all non-Windows platforms](https://github.com/openjdk/jdk/blob/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2/make/autoconf/toolchain.m4#L188).

This pull request has now been integrated.

Changeset: 08f4c1c8
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08f4c1c801c8c3553c1380e1d019a487bd0a25ea
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8349781: make test TEST=gtest fails on WSL

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Wed Feb 12 11:18:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Feb 2025 11:18:09 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v3]
In-Reply-To: <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
Message-ID: <YkOo4JeUggOmnOpEMEnSkTioUw6nKfo085lsdEi9Ro8=.ebd3c087-507b-4b8a-96d0-53b5ae5e49a7@github.com>

On Tue, 11 Feb 2025 17:10:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050
>  - renamed excludes

LGTM now

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23525#pullrequestreview-2611595217

From duke at openjdk.org  Wed Feb 12 13:01:36 2025
From: duke at openjdk.org (anthonio9)
Date: Wed, 12 Feb 2025 13:01:36 GMT
Subject: RFR: 8255785: X11 libraries should not be required by configure
 for headless only
In-Reply-To: <8rnCZ5QGpnxuHCuEA7VvzLbFNOgqLfSzL7gViqBqEWE=.4fd5556b-7a1b-4a0c-8080-6daeaeff6baa@github.com>
References: <8rnCZ5QGpnxuHCuEA7VvzLbFNOgqLfSzL7gViqBqEWE=.4fd5556b-7a1b-4a0c-8080-6daeaeff6baa@github.com>
Message-ID: <Pcg_T9BHWDrpLLeh-r8MdmVSM4lqA487X0Cm2YqRjvU=.f2535bc7-3198-4048-834e-fce9f941dc4f@github.com>

On Tue, 3 Nov 2020 00:33:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If we build a headless only JDK, configure will require X11 libraries and headers to be present. This used to be necessary, but thanks to massive cleanups in the AWT headless code, this is no longer the case.
> 
> We should fix configure so that headless can be built without X11 libraries and headers.

Has the support for headless without X11 been merged to the main branch? The official documentation still mentions the need to provide X11 libraries. What's the status @magicus?

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

PR Comment: https://git.openjdk.org/jdk/pull/1025#issuecomment-2640105651

From jiangli at openjdk.org  Wed Feb 12 16:32:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 16:32:15 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>
Message-ID: <3H_Mfd3MStwDvkvS6pFHUQnNy8iT5Cig_beneRBqdxo=.61c11b41-8b04-4b49-9552-84ee5f5aff71@github.com>

On Wed, 12 Feb 2025 05:07:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
>> 
>> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
>> 
>> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 303:
> 
>> 301: #else
>> 302: 
>> 303:     if (JVM_IsStaticallyLinked()) {
> 
> These kinds of checks on behalf of a statically linked build are quite intrusive.
> Perhaps there is no alternative, but still.
> SFAIK, at this time, no one is under any obligation to test this works, or to know how not to break it.
> So I will approve with those caveats.

Thanks for the review, @prrace!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23574#discussion_r1953012595

From jiangli at openjdk.org  Wed Feb 12 16:32:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 16:32:15 GMT
Subject: Integrated: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <vPBLLepfNl8SWstW0sisWsdyyuoAuc8EqjbWYj2uTgM=.d2d96b7f-f803-4162-8c5d-e7a19259dcf3@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

This pull request has now been integrated.

Changeset: 332d87cc
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd
Stats:     15 lines in 2 files changed: 15 ins; 0 del; 0 mod

8349859: Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: prr

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

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

From kvn at openjdk.org  Wed Feb 12 17:27:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 17:27:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

This broke our builds:

/jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
/jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
  307 |         FT_Property_Set(library, module, property, (void*)(&version));
      |         ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I don't see GHA testing enabled for this repo.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654389337
PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654390478

From jiangli at openjdk.org  Wed Feb 12 17:29:11 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 17:29:11 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
Message-ID: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>

On Wed, 12 Feb 2025 07:00:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @bplb You may have to double check that this works for us.

Thanks!

@bplb, please let me know your internal testing result. If there's no additional internal test source changes in those native libraries, I think testing should not run into any issue. These tests native code only uses standard JNI APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2654396167

From bpb at openjdk.org  Wed Feb 12 17:32:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 17:32:13 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
Message-ID: <4qjjVJr1gRimdsj5vZh4j8Aa3MaYnWdAKo9u4oHrdvI=.afd91988-46a1-4f25-bda9-c3090f944341@github.com>

On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> please let me know your internal testing result.

Sure, of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2654400869

From jiangli at openjdk.org  Wed Feb 12 17:49:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 17:49:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
Message-ID: <1FgaLnyh90Fm6UnoKXOZbqGDjIH6LT8UP9gOGKbtPhY=.25e5ee06-663f-4f9b-b275-1f5123a63364@github.com>

On Wed, 12 Feb 2025 17:24:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I don't see GHA testing enabled for this repo.

GHA testing is enabled: https://github.com/openjdk/jdk/pull/23574/checks. All tests passed in GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654440345

From kvn at openjdk.org  Wed Feb 12 17:53:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 17:53:44 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
Message-ID: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>

Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

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

Commit messages:
 - 8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c

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

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

From jiangli at openjdk.org  Wed Feb 12 18:03:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:03:10 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <6jUvH-fUYBSpD6WdLyM3R1AWjEBmKAwLZIak54kTvsQ=.2cebe076-2493-4326-82f8-a5d654c134be@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

Looks good. Thanks!

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

Marked as reviewed by jiangli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23591#pullrequestreview-2612791365

From kvn at openjdk.org  Wed Feb 12 18:12:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 18:12:09 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <HBMfzVxfvfqxYq47UElAQxyy-t_tc9PWmvuXvjSFVKk=.41238a27-f571-43fd-8a72-d6682356ed79@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

I will wait GHA builds finish

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

PR Comment: https://git.openjdk.org/jdk/pull/23591#issuecomment-2654490638

From shade at openjdk.org  Wed Feb 12 18:18:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Feb 2025 18:18:21 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <s4fJRmKF_fKbz0vML0bvMcw02WzXq7NFre891nyvY_o=.788ee812-46ae-4778-9531-a302c77869fa@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23591#pullrequestreview-2612827688

From jiangli at openjdk.org  Wed Feb 12 18:20:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:20:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
Message-ID: <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>

On Wed, 12 Feb 2025 17:24:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This broke our builds:
> 
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
>   307 |         FT_Property_Set(library, module, property, (void*)(&version));
>       |         ^~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> ```

Thanks for reporting the issue. Sorry for introducing a breakage (again). 

Does the issue occur with the same build platform run into https://bugs.openjdk.org/browse/JDK-8349752?

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654506966

From kvn at openjdk.org  Wed Feb 12 18:29:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 18:29:16 GMT
Subject: Integrated: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <i-VhoUO90e-tXnGXTazOjpHHP-mvV--WvvUeTEBIYo8=.8a9334b6-d070-4135-a745-273399a2750d@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

This pull request has now been integrated.

Changeset: 336d0d85
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/336d0d8592aed734e7b8139e1ecd71d33825c75a
Stats:     15 lines in 2 files changed: 0 ins; 15 del; 0 mod

8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: jiangli, shade

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

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

From jiangli at openjdk.org  Wed Feb 12 18:30:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:30:14 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
 <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>
Message-ID: <Jp9LvQfM0K9xW0Fzeo_fgDZXPtgnXXTm5NBfZVQ_zkA=.25c9999f-6e6f-4324-a4bc-d00c93c70839@github.com>

On Wed, 12 Feb 2025 18:17:16 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This broke our builds:
> 
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
>   307 |         FT_Property_Set(library, module, property, (void*)(&version));
>       |         ^~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> ```

Some analysis:

FT_Property_Set is declared in ftmodapi.h (https://github.com/openjdk/jdk/blob/4b463ee70eceb94fdfbffa5c49dd58dcc6a6c890/src/java.desktop/share/native/libfreetype/include/freetype/ftmodapi.h#L413). The header file is properly included by freetypeScaler.c:

https://github.com/openjdk/jdk/blob/4b463ee70eceb94fdfbffa5c49dd58dcc6a6c890/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#L46

#include FT_MODULE_H


I'm puzzled why it cannot find `FT_Property_Set`. @vnkozlov Can you please provide more info about the build platform? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654529482

From henryjen at openjdk.org  Wed Feb 12 18:40:17 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 12 Feb 2025 18:40:17 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

based on the comment, perhaps the library version on the failed host is old? I suppose you can invoke the function as dynamic version with the returned pointer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654548863

From mikael at openjdk.org  Wed Feb 12 18:44:14 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 12 Feb 2025 18:44:14 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <-BqCWg6rzve90JPXF37v-Pz1cVE8sKD6Vh7A3QvZvBQ=.5b06fa8a-3f3d-483f-8a26-b68bbef9813b@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

If it helps, the freetype headers/libraries we're using come from the "devkit", and on linux-x64 we're using an Oracle Linux 6.4 sysroot (see https://github.com/openjdk/jdk/blob/master/make/devkit/Tools.gmk#L62).

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654557344

From jiangli at openjdk.org  Wed Feb 12 18:51:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:51:15 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>
Message-ID: <slYnL1Nem1c-AY_H0_-8nkz4DOuHLPtVjZ5e2aC6J6I=.5008d035-ee44-40bd-a67b-35bc394c1a05@github.com>

On Wed, 12 Feb 2025 18:37:11 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
>> 
>> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
>> 
>> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.
>
> based on the comment, perhaps the library version on the failed host is old? I suppose you can invoke the function as dynamic version with the returned pointer.

Thanks, @slowhog and @vidmik!

I notice the compilation command has `-I/usr/include/freetype2`. I think that makes sense when using system provided libfreetype and not the bundled one. If the library version on the build system is old, it probably can help explain why it cannot find the function.

So looks like we have to also call the function using the address from symbol lookup, for the static case. I was hoping that we don't have to do that, but looks like we cannot avoid.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654571311

From mikael at openjdk.org  Wed Feb 12 18:57:18 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 12 Feb 2025 18:57:18 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

I can confirm that `FT_Property_Set` does not seem to be there at all in the (older?) version of freetype from OL6.4.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654582536

From jiangli at openjdk.org  Wed Feb 12 19:01:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 19:01:13 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>
Message-ID: <GibAZtFTt9xqwO95cJWeLqZqpUJz4zC9acxd417Tgbg=.315f4b47-8662-4c60-9051-3e867e36d660@github.com>

On Wed, 12 Feb 2025 18:54:17 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> I can confirm that `FT_Property_Set` does not seem to be there at all in the (older?) version of freetype from OL6.4.

Thanks for confirming!

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654591105

From prr at openjdk.org  Wed Feb 12 19:36:18 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 19:36:18 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

Looks like you will have to more fully copy the pattern in the dynamic linking case.

I am surprised that we still have something from OL 6.x .. I thought we were about to obsolete OL 7.x

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654665427

From honkar at openjdk.org  Wed Feb 12 19:44:09 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Feb 2025 19:44:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <dxT9EqX6MU33JeSQR2tTW145SWibmjLKnfMKFeNgC7U=.92a50cb5-1117-42f0-a31f-3bbb1ca69a04@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

> @honkar-jdk do you have the latest/newest jdk head, especially this change is important 8349214: Improve size optimization flags for MSVC builds [40603a5](https://github.com/openjdk/jdk/commit/40603a5bf039eef03c157bfc49ac8ea2229a94de)
> 
> Before the SIZE opt flags for MSVC were bad.

Looks like I didn't have this changeset in my repo. 
With the size opt flag of `-O1` , I see similar .dll file sizes as before. LGTM now.


201K Feb 12 11:29 splashscreen.dll
177K Feb 12 11:30 splashscreen.dll.map
1.6M Feb 12 11:30 splashscreen.dll.pdb

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2613025937

From zsong at openjdk.org  Wed Feb 12 19:55:44 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Feb 2025 19:55:44 GMT
Subject: RFR: 8349934: Wrong file regex for copyright header format check in
 .jcheck/conf
Message-ID: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>

The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).

After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".

`files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`

This redundant "|" prevents the regex from matching any string.

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

Commit messages:
 - JDK-8349934

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

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

From zsong at openjdk.org  Wed Feb 12 19:55:44 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Feb 2025 19:55:44 GMT
Subject: RFR: 8349934: Wrong file regex for copyright header format check
 in .jcheck/conf
In-Reply-To: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
References: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
Message-ID: <kMweoN7CsCOwAgnNVgGITJDOMUDqh2UiTO7EWmvh3V8=.f8271639-6c6e-4a98-847d-f55aad635db7@github.com>

On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).
> 
> After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".
> 
> `files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`
> 
> This redundant "|" prevents the regex from matching any string.

I have tested it in playground
https://github.com/openjdk/playground/pull/224

Here is the .jcheck/conf
https://github.com/openjdk/playground/blob/testSKARA/.jcheck/conf

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

PR Comment: https://git.openjdk.org/jdk/pull/23598#issuecomment-2654706707

From jiangli at openjdk.org  Wed Feb 12 20:24:19 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 20:24:19 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
Message-ID: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>

Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

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

Commit messages:
 - Redo JDK-8349859 fix. Instead of calling FT_Property_Set directly, call the function using the address returned by lookup.

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

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

From jiangli at openjdk.org  Wed Feb 12 20:25:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 20:25:22 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>
Message-ID: <qWTxT4XLfGzdyPkUncrs9hkIAGPGDm8Is8fdaCIpSuA=.fcdbd7fd-1596-4202-892d-2d13e3b55204@github.com>

On Wed, 12 Feb 2025 19:33:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Looks like you will have to more fully copy the pattern in the dynamic linking case.
 
Yeah, we still have to call it using the function address for the static case. I sent https://github.com/openjdk/jdk/pull/23600.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654762430

From erikj at openjdk.org  Wed Feb 12 20:42:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Feb 2025 20:42:13 GMT
Subject: RFR: 8349934: Wrong file regex for copyright header format check
 in .jcheck/conf
In-Reply-To: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
References: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
Message-ID: <Ztf2CIB6gCq1WJcj5tclRulKU7q2tdI6R8LZquWPVcE=.e55e06e3-f558-4f53-b445-36e6d28645d6@github.com>

On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).
> 
> After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".
> 
> `files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`
> 
> This redundant "|" prevents the regex from matching any string.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23598#pullrequestreview-2613143124

From erikj at openjdk.org  Wed Feb 12 20:42:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Feb 2025 20:42:20 GMT
Subject: RFR: 8349933: Mixing of includes and snippets stack causes the wrong
 -post snippet to be included
Message-ID: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>

The new framework for tracing makefile inclusion has a bug. In the Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and THIS_SNIPPET respectively are restored from the HELPER_STACK variable. The problem is that we can't know if the next item on the stack is a previous "include" or "snippet". In a complex tree of includes/snippets, this can cause the wrong custom -post file to get included.

My proposed fix is to split HELPER_STACK into two variables, INCLUDE_STACK and SNIPPET_STACK, so we keep track of which files were includes and which ones were snippets. When printing indentations we just concatenate these variables to get the total stack size.

This patch fixes the observed issue for me locally. I'm running extensive testing on it.

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

Commit messages:
 - JDK-8349933

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

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

From prr at openjdk.org  Wed Feb 12 21:05:11 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 21:05:11 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
Message-ID: <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>

On Wed, 12 Feb 2025 20:19:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

It might be prudent this time to put this through the Oracle internal build system. Not just GHA.
I'll submit a build shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2654838060

From zsong at openjdk.org  Wed Feb 12 21:29:10 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Feb 2025 21:29:10 GMT
Subject: RFR: 8349934: Wrong file regex for copyright header format check
 in .jcheck/conf
In-Reply-To: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
References: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
Message-ID: <U_32T_I4fPnuiLP9WoB7B_QnNHQJGsqVh-Yz9vltKyA=.7900e0d1-1326-4726-9c39-c5f21606698e@github.com>

On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).
> 
> After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".
> 
> `files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`
> 
> This redundant "|" prevents the regex from matching any string.

Thank you for the quick review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23598#issuecomment-2654877190

From duke at openjdk.org  Wed Feb 12 21:29:10 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Feb 2025 21:29:10 GMT
Subject: RFR: 8349934: Wrong file regex for copyright header format check
 in .jcheck/conf
In-Reply-To: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
References: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
Message-ID: <KcBV1aUpEPECCmI4fmOR2ywSM6J190cRu84j-WcJW40=.8c198be5-d197-4b56-958c-4fbd56491a35@github.com>

On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).
> 
> After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".
> 
> `files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`
> 
> This redundant "|" prevents the regex from matching any string.

@zhaosongzs 
Your change (at version 6e2a08c3f4eefc24c64448db184faf19dc182fd8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23598#issuecomment-2654878838

From jiangli at openjdk.org  Wed Feb 12 21:31:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 21:31:10 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
 <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>
Message-ID: <m-KkvF1oSVc_dPPMG-bSPLQcWodcfPoQ8pp3ODNdgvo=.1c5ba069-f369-4852-b84c-e3661e0e3d58@github.com>

On Wed, 12 Feb 2025 21:03:02 GMT, Phil Race <prr at openjdk.org> wrote:

> It might be prudent this time to put this through the Oracle internal build system. Not just GHA. I'll submit a build shortly.

Thank you, @prrace!

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2654882500

From zsong at openjdk.org  Wed Feb 12 21:39:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Feb 2025 21:39:15 GMT
Subject: Integrated: 8349934: Wrong file regex for copyright header format
 check in .jcheck/conf
In-Reply-To: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
References: <f58Zng36dUuzeaMi2xUQDkVar3srzsYiWLJvUyyv73k=.68782e7f-f481-4710-a161-59e61edd71cd@github.com>
Message-ID: <X9j5sDpm5Q99qcKdHYxVsJ4awWn3wskSGmz3GnxvZRI=.71b314e5-21ac-49e6-bb66-92ec48e2c9b5@github.com>

On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

> The copyright header format check was introduced in [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user recently reported that the check doesn't catch incorrect copyright headers in this pr(https://github.com/openjdk/jdk/pull/23550).
> 
> After investigation, I found that the issue was caused by the file regex in .jcheck/conf. There is a redundant "|" character after ".*.jar".
> 
> `files=^(?!LICENSE|license.txt|.*.bin|.*.gif|.*.jpg|.*.png|.*.icon|.*.tiff|.*.dat|.*.patch|.*.wav|.*.class|.*-header|.*.jar|).*`
> 
> This redundant "|" prevents the regex from matching any string.

This pull request has now been integrated.

Changeset: 7a0832f5
Author:    Zhao Song <zsong at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a0832f5487cb7586131f6c4e0b90300f6de5dec
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8349934: Wrong file regex for copyright header format check in .jcheck/conf

Reviewed-by: erikj

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

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

From tim.bell at oracle.com  Wed Feb 12 22:01:52 2025
From: tim.bell at oracle.com (tim.bell at oracle.com)
Date: Wed, 12 Feb 2025 14:01:52 -0800
Subject: CFV: Dissolve The JDK 7 and JDK 8 Projects
In-Reply-To: <e4b1a48e-5935-4be3-b4d8-2044374ededb@oracle.com>
References: <e4b1a48e-5935-4be3-b4d8-2044374ededb@oracle.com>
Message-ID: <5bb267a5-44f6-40ad-b903-8ce8dd60ab8d@oracle.com>

The CFV to Dissolve the JDK 7 and JDK 8 Projects [1] is now closed.

Valid votes cast by Project Members per the census [2] are :

Yes: 5
No: 0

According to the Bylaws definition of Sponsorship [3] and Three-Vote 
Consensus [4], this is sufficient to Dissolve the projects.

The project mailing lists [5], [6] are archived.? Source code 
repositories [7], [8] are read-only.

Please record this decision and remove the projects from the OpenJDK 
census [9].

Thank you-

Tim Bell
Build group Lead

[1] https://mail.openjdk.org/pipermail/build-dev/2025-January/048567.html
[2] https://openjdk.org/census#build
[3] https://openjdk.org/bylaws#sponsor
[4] https://openjdk.org/bylaws#lazy-consensus
[5] https://mail.openjdk.org/mailman/listinfo/jdk7-dev
[6] https://mail.openjdk.org/mailman/listinfo/jdk8-dev
[7] https://hg.openjdk.org/jdk7
[8] https://hg.openjdk.org/jdk8
[9] https://openjdk.org/census#projects


From bpb at openjdk.org  Wed Feb 12 23:40:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 23:40:12 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
Message-ID: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>

On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I think testing should not run into any issue

I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests

java/nio/jni/NewDirectByteBuffer.java
java/nio/channels/FileChannel/directio
java/nio/channels/spi/SelectorProvider/inheritedChannel

which the proposed change specifically would affect.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2655080371

From jiangli at openjdk.org  Thu Feb 13 00:21:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 00:21:10 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
 <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
Message-ID: <lVr7e8WnH5R7T2iSUWJ-bK7lUxL4YNbeF9GWVT3a9KQ=.875b5023-db02-43d9-aa15-5de9f6e848f3@github.com>

On Wed, 12 Feb 2025 23:37:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I think testing should not run into any issue
> 
> I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests
> 
> ```
> java/nio/jni/NewDirectByteBuffer.java
> java/nio/channels/FileChannel/directio
> java/nio/channels/spi/SelectorProvider/inheritedChannel
> ```
> 
> which the proposed change specifically would affect.

Thank you, @bplb!

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2655140100

From jiangli at openjdk.org  Thu Feb 13 01:33:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 01:33:14 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <Tx21SBZAz5q5aRSygne8VQVSPHvfOeki1H1uWyvje64=.cfc49b7d-eef6-4e0a-8ef0-f4d54ba39a48@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
 <Tx21SBZAz5q5aRSygne8VQVSPHvfOeki1H1uWyvje64=.cfc49b7d-eef6-4e0a-8ef0-f4d54ba39a48@github.com>
Message-ID: <OzzK-eOIAWJIadzDx_p8G9bry5uqlbEm7-x6-KYsM8Y=.facbdfd2-c89f-462c-82d0-2556254c61b4@github.com>

On Wed, 12 Feb 2025 21:57:13 GMT, Phil Race <prr at openjdk.org> wrote:

> The build tasks all succeeded (well, there's a not-relevant windows installer one still in progress, so never mind about that).

Thanks again, @prrace! I'll integrate tomorrow early morning.

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2655226648

From cjplummer at openjdk.org  Thu Feb 13 01:55:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 01:55:22 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
Message-ID: <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>

On Wed, 12 Feb 2025 08:59:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This is what I get with HIGH , on Linux x86_64 (gcc 11.3 used)
> 
> du -sh images/jdk/lib/libjdwp.* 2.0M images/jdk/lib/libjdwp.debuginfo 316K images/jdk/lib/libjdwp.so

So it's about a 5% footprint increase to go from LOW to HIGH, and about a 10% footprint savings to go from LOW to SIZE. What specific gcc -O flag do each of these map to? I figure SIZE == -Os, HIGH == -O3. Not sure about LOW, but if it is -O1, then -Os will probably give a performance increase since it is -O2 minus some code bloat optimizations and plus some code size optimizations.

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

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

From jpai at openjdk.org  Thu Feb 13 06:58:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Feb 2025 06:58:13 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1
In-Reply-To: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
Message-ID: <Jqevmo_BuBjCocLNT-WwAf2_xJYHz3pT2hUe5WSHN38=.afbe3018-0692-44ee-acf4-85a1209a704c@github.com>

On Thu, 29 Aug 2024 11:26:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

Marked as reviewed by jpai (Reviewer).

This looks good to me. Before integrating, it might be a good idea to also check with Roger if this jtreg release works fine against the project (valhalla?) where a previous jtreg release had shown some issues.

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2614019053
PR Comment: https://git.openjdk.org/jdk/pull/20766#issuecomment-2655689063

From jpai at openjdk.org  Thu Feb 13 07:22:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Feb 2025 07:22:10 GMT
Subject: RFR: 8349933: Mixing of includes and snippets stack causes the
 wrong -post snippet to be included
In-Reply-To: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
References: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
Message-ID: <MwxW5S0rdl85aPJyrHq8b5eBDrCmrkZgzZxz4zQP_Fc=.4276179a-ba35-4075-bec0-bfb3b24f0f73@github.com>

On Wed, 12 Feb 2025 20:37:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The new framework for tracing makefile inclusion has a bug. In the Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and THIS_SNIPPET respectively are restored from the HELPER_STACK variable. The problem is that we can't know if the next item on the stack is a previous "include" or "snippet". In a complex tree of includes/snippets, this can cause the wrong custom -post file to get included.
> 
> My proposed fix is to split HELPER_STACK into two variables, INCLUDE_STACK and SNIPPET_STACK, so we keep track of which files were includes and which ones were snippets. When printing indentations we just concatenate these variables to get the total stack size.
> 
> This patch fixes the observed issue for me locally. I'm running extensive testing on it.

I tried this patch on a Windows system where the build had been failing for me. The build (`make images`) now completes successfully with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/23601#issuecomment-2655726407

From mbaesken at openjdk.org  Thu Feb 13 08:17:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 08:17:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <D1T_WjSdi0OTz4RvSV7ouCs8rztBHMvdV4UNldiCEEw=.4ddafb59-21c3-4f4d-8678-107d5876e987@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

Thanks for looking into it !
Seems I need another re review ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2655824223

From mbaesken at openjdk.org  Thu Feb 13 09:11:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 09:11:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
Message-ID: <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>

On Thu, 13 Feb 2025 01:52:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> So it's about a 5% footprint increase to go from LOW to HIGH, and about a 10% footprint savings to go from LOW to SIZE. What specific gcc -O flag do each of these map to? I figure SIZE == -Os, HIGH == -O3. Not sure about LOW, but if it is -O1, then -Os will probably give a performance increase since it is -O2 minus some code bloat optimizations and plus some code size optimizations.


Please see 
https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L310

On gcc/clang , SIZE is indeed -OS ;  HIGH is -O3;  LOW (=NORM) is -O2 .
'minus some code bloat optimizations'  yes  some alignment (-falign*) options are omitted with -Os (see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 

Btw what is also interesting is LTO optimization ;  with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
But currently we have LTO support only for hotspot.

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

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

From mbaesken at openjdk.org  Thu Feb 13 14:19:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 14:19:15 GMT
Subject: Integrated: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <tHNtniywJCIVeIIWdJPbjrgZ9s2WSkkD9JfztTnRxFg=.273beeb5-307e-44f3-82b4-24acc8edc3e9@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

This pull request has now been integrated.

Changeset: c2fc9478
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2fc94782669ae1645014ee3bfeba957dbff4669
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8349378: Build splashscreen lib with SIZE optimization

Reviewed-by: erikj, prr, honkar

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

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

From jiangli at openjdk.org  Thu Feb 13 15:47:35 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 15:47:35 GMT
Subject: Integrated: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
Message-ID: <5kUCUe3yTdNhqIW39aJrNEC3181g1G4i3dzPFsnakP8=.0a49b91d-3ea8-46f2-b38b-ae135386b9a7@github.com>

On Wed, 12 Feb 2025 20:19:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

This pull request has now been integrated.

Changeset: 18958c62
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18958c6298bf5cc5495375e2940b640b04ec9ccb
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8349925: [REDO] Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: prr

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

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

From iklam at openjdk.org  Thu Feb 13 17:50:26 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Feb 2025 17:50:26 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true"
Message-ID: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>

When running HotSpot jtreg tests in the "AOT mode", for example:


make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable


Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:

https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744

After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.

** Changes in this PR **

This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

Commit messages:
 - 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true"

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

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

From bpb at openjdk.org  Thu Feb 13 17:58:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 17:58:17 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <1XiLaYYO6j9Gb_iLTk0t8shVf7wg8f1NBDUiC7oYny4=.a89e5258-edc9-421a-ac50-dbc9240ff456@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23575#pullrequestreview-2615832041

From cjplummer at openjdk.org  Thu Feb 13 18:28:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 18:28:18 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
Message-ID: <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>

On Thu, 13 Feb 2025 09:08:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Btw what is also interesting is LTO optimization ; with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
> But currently we have LTO support only for hotspot.

LTO support was added for minimal VM, which doesn't support JVMTI and therefore does not support the debug agent, so that's probably why support for it was never added to the debug agent. I thought it was added for some of the libs though, like libjava.so, but I could be wrong.

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

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

From jiangli at openjdk.org  Thu Feb 13 19:11:23 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 19:11:23 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
 <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
Message-ID: <l9H7HMOlzPnZLp1-b_BgTJCBh0iYyfNSZ_IUEmPtWRA=.31aff524-c503-40f4-8006-f8b6dcb1bed6@github.com>

On Wed, 12 Feb 2025 23:37:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> @bplb You may have to double check that this works for us.
>> 
>> Thanks!
>> 
>> @bplb, please let me know your internal testing result. If there's no additional internal test source changes in those native libraries, I think testing should not run into any issue. These tests native code only uses standard JNI APIs.
>
>> I think testing should not run into any issue
> 
> I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests
> 
> java/nio/jni/NewDirectByteBuffer.java
> java/nio/channels/FileChannel/directio
> java/nio/channels/spi/SelectorProvider/inheritedChannel
> 
> which the proposed change specifically would affect.

@bplb Thanks again for the review and running internal testing!

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2657488985

From jiangli at openjdk.org  Thu Feb 13 19:11:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 19:11:24 GMT
Subject: Integrated: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <c2d8nrcps491E74Q1DUqGJ_x8H8xoYEjTT-_mNi3z4o=.6fc34bfd-8600-4d13-805c-5eb91315ebf6@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

This pull request has now been integrated.

Changeset: 2eac490b
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2eac490bd22f5488a60e59f93ce54d4babf33c23
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8349868: Remove unneeded libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel

Reviewed-by: bpb

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

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

From erikj at openjdk.org  Thu Feb 13 19:44:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 13 Feb 2025 19:44:17 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true"
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <UJyIIwhjDoBiZEKk4l5GTsF3HoBF9aDlSXUKgCGZhew=.d3dfc5f8-69fe-4207-98f9-2b7afdc7ccb2@github.com>

On Thu, 13 Feb 2025 17:45:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

make/RunTests.gmk line 734:

> 732: 	$$(call MakeDir, $$($1_TEST_SUPPORT_DIR)/aot)
> 733: 
> 734: 	$(info AOT: Create cache configuration) \

Please use logging framework for any messages. To get something to print by default `$(call LogWarn, ...). While here, please also clean up the left over debug $$(info ) left over further down in this file that we weren't able to point out in the original review.

make/RunTests.gmk line 737:

> 735: 	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/aot, ( \
> 736: 	    $(CD) $$($1_AOT_JDK_DIR); \
> 737: 	    $(JDK_UNDER_TEST)/bin/javac -d . $(TOPDIR)/make/test/SetupAot.java; \

This is putting the compilation output in the current directory, which is the make directory in the workspace. That's not acceptable. Since this is a single class java program, would it be possible to just run it without compilation or would that interfere with the intended behavior? Otherwise it needs to be moved to somewhere else, under `$$($1_TEST_SUPPORT_DIR)`.

I don't like that the compilation is run in the same recipe as the java command running the tool. At the very least those should be split into separate recipes, with separate ExecuteWithLog calls. A cleaner and preferred solution would be to build this tool as part of the test image so we avoid having to compile code during test setup.

make/RunTests.gmk line 741:

> 739: 	                -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \
> 740: 	                -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \
> 741: 	                SetupAot \

Please use 4 spaces indent to follow the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html).

Suggestion:

	    $$(FIXPATH) $(JDK_UNDER_TEST)/bin/java $$($1_VM_OPTIONS) \
	        -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \
	        -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \
	        SetupAot \

make/RunTests.gmk line 744:

> 742: 	))
> 743: 
> 744: 	$$(info AOT: Generate AOT cache $$($1_AOT_JDK_CACHE) with flags: $$($1_VM_OPTIONS))

Again, please use the logging framework. In this case I would recommend `$(call LogInfo, ...)` to reduce spam on the default level. I think one line is enough on warn level for indicating that AOT preparation is taking place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955089073
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955114393
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955094235
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955090525

From iklam at openjdk.org  Fri Feb 14 05:27:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Feb 2025 05:27:09 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v2]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <lMrPxp446Agy-Gu7lGQkz85TBxlozjRheuZvbz1a_Wk=.f70745ab-ad37-4fa5-8f15-d28f39c9c1b6@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

  Comments from @erikj79

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/0a645b69..c1aaf635

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

  Stats: 224 lines in 5 files changed: 142 ins; 62 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/23620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620

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

From iklam at openjdk.org  Fri Feb 14 05:27:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Feb 2025 05:27:10 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v2]
In-Reply-To: <UJyIIwhjDoBiZEKk4l5GTsF3HoBF9aDlSXUKgCGZhew=.d3dfc5f8-69fe-4207-98f9-2b7afdc7ccb2@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <UJyIIwhjDoBiZEKk4l5GTsF3HoBF9aDlSXUKgCGZhew=.d3dfc5f8-69fe-4207-98f9-2b7afdc7ccb2@github.com>
Message-ID: <dZJX-xhHmAdE5ZaGuP8essEpLRC9wtwILKcJLdUABX8=.cae994ee-3f95-40c6-ae97-a83401ba8a02@github.com>

On Thu, 13 Feb 2025 19:20:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments from @erikj79
>
> make/RunTests.gmk line 734:
> 
>> 732: 	$$(call MakeDir, $$($1_TEST_SUPPORT_DIR)/aot)
>> 733: 
>> 734: 	$(info AOT: Create cache configuration) \
> 
> Please use logging framework for any messages. To get something to print by default `$(call LogWarn, ...). While here, please also clean up the left over debug $$(info ) left over further down in this file that we weren't able to point out in the original review.

Fixed. I also fixed the other `$(info)` used by AOT testing.

> make/RunTests.gmk line 737:
> 
>> 735: 	$$(call ExecuteWithLog, $$($1_TEST_SUPPORT_DIR)/aot, ( \
>> 736: 	    $(CD) $$($1_AOT_JDK_DIR); \
>> 737: 	    $(JDK_UNDER_TEST)/bin/javac -d . $(TOPDIR)/make/test/SetupAot.java; \
> 
> This is putting the compilation output in the current directory, which is the make directory in the workspace. That's not acceptable. Since this is a single class java program, would it be possible to just run it without compilation or would that interfere with the intended behavior? Otherwise it needs to be moved to somewhere else, under `$$($1_TEST_SUPPORT_DIR)`.
> 
> I don't like that the compilation is run in the same recipe as the java command running the tool. At the very least those should be split into separate recipes, with separate ExecuteWithLog calls. A cleaner and preferred solution would be to build this tool as part of the test image so we avoid having to compile code during test setup.

I added the class file to the test image.

> make/RunTests.gmk line 741:
> 
>> 739: 	                -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \
>> 740: 	                -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \
>> 741: 	                SetupAot \
> 
> Please use 4 spaces indent to follow the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html).
> 
> Suggestion:
> 
> 	    $$(FIXPATH) $(JDK_UNDER_TEST)/bin/java $$($1_VM_OPTIONS) \
> 	        -Xlog:cds,cds+class=debug:file=$$($1_AOT_JDK_CONF).log \
> 	        -XX:AOTMode=record -XX:AOTConfiguration=$$($1_AOT_JDK_CONF) \
> 	        SetupAot \

Fixed.

> make/RunTests.gmk line 744:
> 
>> 742: 	))
>> 743: 
>> 744: 	$$(info AOT: Generate AOT cache $$($1_AOT_JDK_CACHE) with flags: $$($1_VM_OPTIONS))
> 
> Again, please use the logging framework. In this case I would recommend `$(call LogInfo, ...)` to reduce spam on the default level. I think one line is enough on warn level for indicating that AOT preparation is taking place.

I changed the `$(info)` to `$(call LogWarn)`. Since AOT testing is still a new feature and all the test tasks we use "make test JTREG_AOT_JDK=true" for are for the purpose of testing AOT, it's better to print out the messages related to the AOT cache by default to help with diagnosing test failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955574061
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573695
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573715
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1955573910

From iklam at openjdk.org  Fri Feb 14 05:59:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Feb 2025 05:59:52 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v3]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <xQUfKZ6QssDu555MUIVtDgybJpFUFde18W2hkshAsNw=.7cedf540-6b3a-4fa4-a64a-6c953c4e0f7e@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

 - Merge branch 'master' into 8349953-avoid-edit-aot-config-with-jtreg-aot-jdk
 - Comments from @erikj79
 - 8349953: Avoid editing AOTConfiguration file in "make test JTREG_AOT_JDK=true"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/c1aaf635..ed727488

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

  Stats: 1992 lines in 34 files changed: 1757 ins; 122 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/23620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620

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

From syan at openjdk.org  Fri Feb 14 07:25:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Feb 2025 07:25:40 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE
Message-ID: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>

Hi all,

Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.

After this PR, below JMH tests will run passes.


org.openjdk.bench.javax.xml.DOM.testBuild
org.openjdk.bench.javax.xml.DOM.testModify
org.openjdk.bench.javax.xml.DOM.testWalk
org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
org.openjdk.bench.javax.xml.STAX.testParse


Test command:


rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done


Change has been verified locally, no risk.

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

Commit messages:
 - 8350051: [JMH] Several tests fails NPE

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

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

From mbaesken at openjdk.org  Fri Feb 14 08:34:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Feb 2025 08:34:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
 <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
Message-ID: <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>

On Thu, 13 Feb 2025 18:25:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Btw what is also interesting is LTO optimization ; with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
> > But currently we have LTO support only for hotspot.
> 
> LTO support was added for minimal VM, which doesn't support JVMTI and therefore does not support the debug agent, so that's probably why support for it was never added to the debug agent. I thought it was added for some of the libs though, like libjava.so, but I could be wrong.

The jvm feature link time optimization can be configured for a 'normal' JVM, this has afaik nothing to do with a minimal JVM .
Currently this configure option only changes the compile and link flags of libjvm so the compile and link flags of the JDK native libs are not changed.

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

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

From mbaesken at openjdk.org  Fri Feb 14 15:10:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Feb 2025 15:10:22 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
Message-ID: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>

When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
They only occur with ubsan enabled (seems the warnings change a bit in this case).

src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]

src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

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

Commit messages:
 - JDK-8350094

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

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

From weijun at openjdk.org  Fri Feb 14 15:27:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Feb 2025 15:27:12 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v3]
In-Reply-To: <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
Message-ID: <UpYtpjhKaNqMZEwmCNAfjdVrfk2LB3lo3kKykZn-6kA=.1372c391-5e56-46d7-b9a0-39e28a2c1e1a@github.com>

On Tue, 11 Feb 2025 17:10:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050
>  - renamed excludes

test/lib/jdk/test/lib/security/XMLUtils.java line 557:

> 555:     }
> 556: 
> 557:     //////////// MISC ////////////

This is a section break for various groups of methods in this utility class. Before this there has been

    //////////// CONVERT ////////////
    //////////// QUERY AND EDIT ////////////
    //////////// SIGN ////////////
    //////////// VALIDATE ////////////

Can you keep the format?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956321630

From cjplummer at openjdk.org  Fri Feb 14 17:19:15 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 14 Feb 2025 17:19:15 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
 <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
 <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>
Message-ID: <MSZfQ4mczlPT9UMgnKVgAmps0-mXVxsgDQipONR2ZK0=.dc2b08c5-5b02-4c58-9266-fab3cc92b6d9@github.com>

On Fri, 14 Feb 2025 08:32:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jvm feature link time optimization can be configured for a 'normal' JVM, this has afaik nothing to do with a minimal JVM .
> Currently this configure option only changes the compile and link flags of libjvm so the compile and link flags of the JDK native libs are not changed.

Yes, I understand that. It was introduced to support minimal VM, but like all the minimal VM optional support, it was made to be something that could be configured even when not building minimal VM. For example JVMTI is an optional JVM feature. That was done for minmal VM, but you can choose to not include JVMTI when you configure for any build.

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

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

From cstein at openjdk.org  Fri Feb 14 17:50:57 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 14 Feb 2025 17:50:57 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
Message-ID: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>

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

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

  Update TEST.ROOT in `test/docs`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20766/files
  - new: https://git.openjdk.org/jdk/pull/20766/files/8ed92e64..3a92207d

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

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

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

From lmesnik at openjdk.org  Fri Feb 14 18:22:26 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 14 Feb 2025 18:22:26 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v4]
In-Reply-To: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
Message-ID: <ostsu_Wrl22TTU6HACX8drzcVryzsndYIUQieRAn6t0=.1af94ce7-d016-44fc-8974-952fd78ca79f@github.com>

> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - added copyrights
 - replaced commens fix with supress

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23525/files
  - new: https://git.openjdk.org/jdk/pull/23525/files/4813daed..83d688b2

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

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

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

From lmesnik at openjdk.org  Fri Feb 14 18:22:26 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 14 Feb 2025 18:22:26 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v4]
In-Reply-To: <UpYtpjhKaNqMZEwmCNAfjdVrfk2LB3lo3kKykZn-6kA=.1372c391-5e56-46d7-b9a0-39e28a2c1e1a@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
 <UpYtpjhKaNqMZEwmCNAfjdVrfk2LB3lo3kKykZn-6kA=.1372c391-5e56-46d7-b9a0-39e28a2c1e1a@github.com>
Message-ID: <DZ6cz58vArFGJfpLe5vSJtfdVjyQh1SS9nIwMCh4DQU=.ce7c36fb-fe4e-4035-bdee-376ff599ce2f@github.com>

On Fri, 14 Feb 2025 15:24:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - added copyrights
>>  - replaced commens fix with supress
>
> test/lib/jdk/test/lib/security/XMLUtils.java line 557:
> 
>> 555:     }
>> 556: 
>> 557:     // MISC
> 
> This is a section break for various groups of methods in this utility class. Before this there have been
> 
>     //////////// CONVERT ////////////
>     //////////// QUERY AND EDIT ////////////
>     //////////// SIGN ////////////
>     //////////// VALIDATE ////////////
> 
> Can you keep the format?

sure, since such comments are cause warning, i just suppress them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956557342

From jiangli at openjdk.org  Fri Feb 14 18:37:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Feb 2025 18:37:58 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
Message-ID: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>

Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 

- Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
- Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
- Link with `-ldl` explicitly

The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

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

Commit messages:
 - Remove 'lib' prefix from 'java.dll'.
 - Update copyright header year.
 - - Change to call JNU_GetStringPlatformChars, JNU_ClassString and JNU_NewStringPlatform

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

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

From weijun at openjdk.org  Fri Feb 14 19:27:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Feb 2025 19:27:12 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v4]
In-Reply-To: <DZ6cz58vArFGJfpLe5vSJtfdVjyQh1SS9nIwMCh4DQU=.ce7c36fb-fe4e-4035-bdee-376ff599ce2f@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
 <UpYtpjhKaNqMZEwmCNAfjdVrfk2LB3lo3kKykZn-6kA=.1372c391-5e56-46d7-b9a0-39e28a2c1e1a@github.com>
 <DZ6cz58vArFGJfpLe5vSJtfdVjyQh1SS9nIwMCh4DQU=.ce7c36fb-fe4e-4035-bdee-376ff599ce2f@github.com>
Message-ID: <LQNrkg03rQLygxfwwhBxdyMOlG-huKLQFqKAIrGLpEI=.a6276832-590d-4c77-94b8-b0307b993b2d@github.com>

On Fri, 14 Feb 2025 18:19:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/lib/jdk/test/lib/security/XMLUtils.java line 557:
>> 
>>> 555:     }
>>> 556: 
>>> 557:     // MISC
>> 
>> This is a section break for various groups of methods in this utility class. Before this there have been
>> 
>>     //////////// CONVERT ////////////
>>     //////////// QUERY AND EDIT ////////////
>>     //////////// SIGN ////////////
>>     //////////// VALIDATE ////////////
>> 
>> Can you keep the format?
>
> sure, since such comments are cause warning, i just suppress them.

Oh, they were recognized as Markdown javadoc? I didn't think of that.

It's strange that the other 4 show no warning, and then I noticed that changing it to

    //////////// MISC ////////////

    // Adds a new rule to "jdk.xml.dsig.secureValidationPolicy"

can also let the warning go away. The problem is it now treats the `///` line as javadoc and `//` as nothing. This is definitely not right. Maybe I'll do some cleanup later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956622006

From weijun at openjdk.org  Fri Feb 14 19:27:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Feb 2025 19:27:12 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v4]
In-Reply-To: <LQNrkg03rQLygxfwwhBxdyMOlG-huKLQFqKAIrGLpEI=.a6276832-590d-4c77-94b8-b0307b993b2d@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <HgTXDPcSPjjSNohFQAUnvC3BhIG_ETKEDPGmQ90r5Mk=.7004e823-6e6f-464b-9d4e-fc0bbfa3872a@github.com>
 <UpYtpjhKaNqMZEwmCNAfjdVrfk2LB3lo3kKykZn-6kA=.1372c391-5e56-46d7-b9a0-39e28a2c1e1a@github.com>
 <DZ6cz58vArFGJfpLe5vSJtfdVjyQh1SS9nIwMCh4DQU=.ce7c36fb-fe4e-4035-bdee-376ff599ce2f@github.com>
 <LQNrkg03rQLygxfwwhBxdyMOlG-huKLQFqKAIrGLpEI=.a6276832-590d-4c77-94b8-b0307b993b2d@github.com>
Message-ID: <ccyq-Hqg85Inj227Y7st9BP3JHBknWERjoIJgzwapyI=.4ce7c14b-b459-4345-81a1-78b9f37f6dce@github.com>

On Fri, 14 Feb 2025 19:23:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> sure, since such comments are cause warning, i just suppress them.
>
> Oh, they were recognized as Markdown javadoc? I didn't think of that.
> 
> It's strange that the other 4 show no warning, and then I noticed that changing it to
> 
>     //////////// MISC ////////////
> 
>     // Adds a new rule to "jdk.xml.dsig.secureValidationPolicy"
> 
> can also let the warning go away. The problem is it now treats the `///` line as javadoc and `//` as nothing. This is definitely not right. Maybe I'll do some cleanup later.

That said, this is just a test utility class. I'm OK with whatever style at the moment. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956623296

From rriggs at openjdk.org  Fri Feb 14 20:27:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 20:27:11 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
 <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
Message-ID: <UND8A2vuRcH7t_7SZtBzxmyKkV7gW97_gyntt97MHXM=.b9893b67-dc8c-4577-9e3b-d64e66f0f316@github.com>

On Fri, 14 Feb 2025 17:50:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.5.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>> 
>> Tested with tier 1 ? tier 8.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TEST.ROOT in `test/docs`

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2618733162

From iris at openjdk.org  Fri Feb 14 22:14:10 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 14 Feb 2025 22:14:10 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
 <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
Message-ID: <M8RYf71bgOn-nYVgLvKVEzpf4tWwKtDSzzX83k_P3kQ=.9d2cce90-d6f5-4946-9e07-abff68e6a6bd@github.com>

On Fri, 14 Feb 2025 17:50:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.5.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>> 
>> Tested with tier 1 ? tier 8.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TEST.ROOT in `test/docs`

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2618896594

From mdoerr at openjdk.org  Fri Feb 14 22:20:09 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Feb 2025 22:20:09 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <8cTizu5-0p9GQBZWQfdRGCEAeAucuOP0cDjHeTuOf4Q=.301b7f92-1c9e-4c2b-858e-0c36df55056f@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

I think this is ok, but I'd like to see a 2nd review.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23639#pullrequestreview-2618904884

From prr at openjdk.org  Fri Feb 14 22:56:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Feb 2025 22:56:10 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <8N0EDBNDa2s4aQtelzi37nrc3KebUpmZ0qLOa0_Qewk=.97f577c2-81d5-4081-a215-44ecd648e8f0@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

>From looking at the lcms code it cites, this looks like a wholly incorrect warning.
No idea about the hotspot one.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23639#pullrequestreview-2618951869

From iklam at openjdk.org  Sat Feb 15 04:46:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Feb 2025 04:46:56 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v4]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <FGimPsbwgDuWwpvqFdv8FtuTB7tS9NIhnT1hhnsUG9E=.b6de13ea-d278-493f-809b-167d42fa9972@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

  Moved the AOT setup function into SetupAOT.gmk so it can be included by other internal makefiles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/ed727488..81944a2e

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

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

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

From kbarrett at openjdk.org  Mon Feb 17 02:34:11 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 17 Feb 2025 02:34:11 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <lSKr3DhpNGQz3wuA9N4JJa_C29uOxitRWWQrtwAcG58=.be277fc9-4f4a-4b86-87ae-06bc6291d8fc@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

I agree with @prrace race that the cmsmd5 warnings seem incorrect.

The ps_core warning also looks incorrect: based on the immediately
preceding calculations, `len < page_size`.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23639#pullrequestreview-2619857405

From mbaesken at openjdk.org  Mon Feb 17 08:05:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 08:05:14 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <GgQ26hQNpu3vCxMRa8D6NDGTQbdgL8NIJCNz87hkExA=.f2a61d73-4214-48a4-8479-957a4c9b8440@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23639#issuecomment-2662326623

From mbaesken at openjdk.org  Mon Feb 17 08:05:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 08:05:15 GMT
Subject: Integrated: 8350094: Linux gcc 13.2.0 build fails when ubsan is
 enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <FOHpD3pPheQXMeFLeezoIbZ9Euo0n6ABhI6nskeKrgY=.662cae78-618b-49a7-b908-c56589a4c715@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

This pull request has now been integrated.

Changeset: 5e9d72e2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e9d72e2241426c0cf26abadab73e63434d51a4a
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8350094: Linux gcc 13.2.0 build fails when ubsan is enabled

Reviewed-by: mdoerr, prr, kbarrett

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

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

From mbaesken at openjdk.org  Mon Feb 17 09:07:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 09:07:09 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: <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@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 .

btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get

1.8M	./lib/libjdwp.debuginfo
280K	./lib/libjdwp.so

This looks pretty good compared to HIGH or standard (LOW/NORM) settings.

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

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

From mbaesken at openjdk.org  Mon Feb 17 14:04:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 14:04:23 GMT
Subject: RFR: 8350202: Tune for Power10 CPUs on Linux ppc64le
Message-ID: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>

Currently we tune for older Power8 CPUs in the libjvm build, this should be adjusted to current Power10.

We do not set (yet) mcpu / mtune in the other native compilation units in the linux ppc64le build; this should we reconsidered.

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

Commit messages:
 - JDK-8350202

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

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

From duke at openjdk.org  Mon Feb 17 19:52:21 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 19:52:21 GMT
Subject: Withdrawn: 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: <y5sbvad1Y5n2bzxGQK97vWP8RTQKIgsvg8EW8xXmJk4=.8629765e-ff9d-4f6b-a609-ff631a30e0d2@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/...

This pull request has been closed without being integrated.

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

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

From cjplummer at openjdk.org  Mon Feb 17 22:56:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 17 Feb 2025 22:56:12 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
Message-ID: <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>

On Mon, 17 Feb 2025 09:04:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get
> 
> 1.8M ./lib/libjdwp.debuginfo 280K ./lib/libjdwp.so
> 
> This looks pretty good compared to HIGH or standard (LOW/NORM) settings.

What is the optimization level?

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

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

From jwaters at openjdk.org  Tue Feb 18 00:38:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 18 Feb 2025 00:38:13 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
 <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>
 <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>
Message-ID: <CmQIpwr-hmoDwldTiw1XvSabi5czLufMwZZq-_fAQto=.a0882ec5-ce80-41ac-b398-c8357569f67c@github.com>

On Fri, 17 Jan 2025 13:50:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> > Member
>>> 
>>> Fixing the JVM under LTO is likely to be a heavy undertaking, much more so than just unbreaking compilation and linking of the JVM (Ignoring that the JVM later crashes when the newly compiled JDK is used to build parts of itself), I'm not sure it would be feasible under the current Pull Request
>> 
>> I was able to build the OpenJDK with LTO enabled on Linux and Windows (so the new JVM does not crash in the build). I just had to not enable gtest because this is currently not compiling with LTO enabled.  I was able to run a few benchmarks with the LTO enabled JVM , but  as far as I remember a couple of HS jtreg tests fail with LTO enabled  because they have some expectations that might not (yet) work with LTO.
>> 
>> Regarding gtest, I created
>> https://bugs.openjdk.org/browse/JDK-8346987
>> 8346987: [lto] gtest build fails
>>  Do you think it would be okay to change the build so that the LTO related flags (in case lto is enabled) do not 'go'  into the gtest build ?
>
>> I was able to run a few benchmarks with the LTO enabled JVM , 
>> but as far as I remember a couple of HS jtreg tests fail with LTO enabled because they have some expectations that might not (yet) work with LTO
> 
> On Linux x86_64  (gcc 11.3 devkit) ,  when building with lto enabled, the  jdk  :tier1  jtreg  tests all worked nicely in my environment.
> The HS :tier1 jtreg tests  had  51 failures, 50 in the  serviceability/sa  area .
> Those failures (from  serviceability/sa) seem to have in common that they show such an exception 
> 
>  stderr: [Exception in thread "main" java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:926)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2230)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2200)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2071)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> or   test   serviceability/sa/TestJhsdbJstackMixed.java
> 
>  stderr: [java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:1...

@MBaesken Currently with LTO active on gcc 14 commit e648a907b31fd0d6b746d149fda2a8d5fbe26dc0 is causing serious trouble on my end by mass inlining everything, bloating the JVM to nearly 60MB in size, does HotSpot have the same size issues on your end with LTO? (--enable-jvm-feature-opt-size is off the table because the JVM should ideally be an acceptable size even without that flag, and -Os and LTO doesn't work with gcc anyway)

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

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

From aturbanov at openjdk.org  Tue Feb 18 09:48:13 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Feb 2025 09:48:13 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v4]
In-Reply-To: <FGimPsbwgDuWwpvqFdv8FtuTB7tS9NIhnT1hhnsUG9E=.b6de13ea-d278-493f-809b-167d42fa9972@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <FGimPsbwgDuWwpvqFdv8FtuTB7tS9NIhnT1hhnsUG9E=.b6de13ea-d278-493f-809b-167d42fa9972@github.com>
Message-ID: <Yci83fcgKSHL84-zymHu1v876tytpGBa8RPe_1A1Z-I=.4f504077-a9bd-4d41-ab16-392ec2741cfa@github.com>

On Sat, 15 Feb 2025 04:46:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When running HotSpot jtreg tests in the "AOT mode", for example:
>> 
>> 
>> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
>> 
>> 
>> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
>> 
>> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
>> 
>> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
>> 
>> ** Changes in this PR **
>> 
>> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the AOT setup function into SetupAOT.gmk so it can be included by other internal makefiles

test/jtreg_setup_aot/ExerciseJDKClasses.java line 54:

> 52:         // E.g., use javac to compile a program.
> 53:         for (String tool : tools) {
> 54:             ToolProvider t  = ToolProvider.findFirst(tool)

Suggestion:

            ToolProvider t = ToolProvider.findFirst(tool)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1959398001

From mdoerr at openjdk.org  Tue Feb 18 11:00:10 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Feb 2025 11:00:10 GMT
Subject: RFR: 8350202: Tune for Power10 CPUs on Linux ppc64le
In-Reply-To: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
References: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
Message-ID: <4Dh6qgw6U-_yxU8GWq72J_lONyC0jNjSo27dy1K1xns=.053787d3-33ac-4299-a4f3-71e890ce4a72@github.com>

On Mon, 17 Feb 2025 14:00:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we tune for older Power8 CPUs in the libjvm build, this should be adjusted to current Power10.
> 
> We do not set (yet) mcpu / mtune in the other native compilation units in the linux ppc64le build; this should we reconsidered.

LGTM. I don't think this has any significant impact, but makes sense.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23664#pullrequestreview-2623167391

From mbaesken at openjdk.org  Tue Feb 18 13:23:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Feb 2025 13:23:13 GMT
Subject: RFR: 8350202: Tune for Power10 CPUs on Linux ppc64le
In-Reply-To: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
References: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
Message-ID: <jByqffHgEtgTaNRcskc0uI7EF5a4M-Xc3vfRacm5VXo=.95ea99a4-6d2b-45cc-9820-21fe7e189dc6@github.com>

On Mon, 17 Feb 2025 14:00:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we tune for older Power8 CPUs in the libjvm build, this should be adjusted to current Power10.
> 
> We do not set (yet) mcpu / mtune in the other native compilation units in the linux ppc64le build; this should we reconsidered.

Hi Martin, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/23664#issuecomment-2665696622

From mbaesken at openjdk.org  Tue Feb 18 13:23:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Feb 2025 13:23:14 GMT
Subject: Integrated: 8350202: Tune for Power10 CPUs on Linux ppc64le
In-Reply-To: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
References: <JaRmAM_eWtctURw7WkktHLXAi-cOk9l4BA1_fy3CEfk=.45556901-3c78-4f2c-9b4c-8a605dfdd45d@github.com>
Message-ID: <izo6Nv6P60jPaXkyhFGh4-5n53ASB1s5IyDa_IH_Euk=.c85b49b9-5e36-468c-bf09-01c51a007d80@github.com>

On Mon, 17 Feb 2025 14:00:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we tune for older Power8 CPUs in the libjvm build, this should be adjusted to current Power10.
> 
> We do not set (yet) mcpu / mtune in the other native compilation units in the linux ppc64le build; this should we reconsidered.

This pull request has now been integrated.

Changeset: e1d0a9c8
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1d0a9c832ef3e92faaed7f290ff56c0ed8a9d94
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8350202: Tune for Power10 CPUs on Linux ppc64le

Reviewed-by: mdoerr

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

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

From mbaesken at openjdk.org  Tue Feb 18 13:48:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Feb 2025 13:48:22 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
 <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>
 <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>
Message-ID: <XNz06jGNCQw0e76tYuoBoBfhivU-Aq6x2rF0oL4p06c=.eec98ee4-bd1e-442e-8703-e76acda8ec66@github.com>

On Fri, 17 Jan 2025 13:50:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> > Member
>>> 
>>> Fixing the JVM under LTO is likely to be a heavy undertaking, much more so than just unbreaking compilation and linking of the JVM (Ignoring that the JVM later crashes when the newly compiled JDK is used to build parts of itself), I'm not sure it would be feasible under the current Pull Request
>> 
>> I was able to build the OpenJDK with LTO enabled on Linux and Windows (so the new JVM does not crash in the build). I just had to not enable gtest because this is currently not compiling with LTO enabled.  I was able to run a few benchmarks with the LTO enabled JVM , but  as far as I remember a couple of HS jtreg tests fail with LTO enabled  because they have some expectations that might not (yet) work with LTO.
>> 
>> Regarding gtest, I created
>> https://bugs.openjdk.org/browse/JDK-8346987
>> 8346987: [lto] gtest build fails
>>  Do you think it would be okay to change the build so that the LTO related flags (in case lto is enabled) do not 'go'  into the gtest build ?
>
>> I was able to run a few benchmarks with the LTO enabled JVM , 
>> but as far as I remember a couple of HS jtreg tests fail with LTO enabled because they have some expectations that might not (yet) work with LTO
> 
> On Linux x86_64  (gcc 11.3 devkit) ,  when building with lto enabled, the  jdk  :tier1  jtreg  tests all worked nicely in my environment.
> The HS :tier1 jtreg tests  had  51 failures, 50 in the  serviceability/sa  area .
> Those failures (from  serviceability/sa) seem to have in common that they show such an exception 
> 
>  stderr: [Exception in thread "main" java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:926)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2230)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2200)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2071)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> or   test   serviceability/sa/TestJhsdbJstackMixed.java
> 
>  stderr: [java.lang.InternalError: Metadata does not appear to be polymorphic
> 	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:1...

> @MBaesken Currently with LTO active on gcc 14 commit [e648a90](https://github.com/openjdk/jdk/commit/e648a907b31fd0d6b746d149fda2a8d5fbe26dc0) is causing serious trouble on my end by mass inlining everything, bloating the JVM to nearly 60MB in size, does HotSpot have the same size issues on your end with LTO? (--enable-jvm-feature-opt-size is off the table because the JVM should ideally be an acceptable size even without that flag, and -Os and LTO doesn't work with gcc anyway)

On my end we used gcc11 in the past and now test gcc13.  Both work nicely,  no libjvm.so bloat has been observed with lto.
Maybe there is some issue/difference with gcc14 but so far we did not test with this version.

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

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

From rriggs at openjdk.org  Tue Feb 18 14:13:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Feb 2025 14:13:11 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
 <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
Message-ID: <ltfjQ85cWG6g1xJD0O-0Qv2nMgkQmAojzeAfCGaIHh4=.05a4b498-2c5c-4898-be63-17f636815a62@github.com>

On Fri, 14 Feb 2025 17:50:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.5.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>> 
>> Tested with tier 1 ? tier 8.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TEST.ROOT in `test/docs`

fyi, the Valhalla build works fine with jtreg 7.5.1 (and a few other updates to tests).

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

PR Comment: https://git.openjdk.org/jdk/pull/20766#issuecomment-2665830146

From weijun at openjdk.org  Tue Feb 18 18:55:45 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 18 Feb 2025 18:55:45 GMT
Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary
 [v4]
In-Reply-To: <ostsu_Wrl22TTU6HACX8drzcVryzsndYIUQieRAn6t0=.1af94ce7-d016-44fc-8974-952fd78ca79f@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
 <ostsu_Wrl22TTU6HACX8drzcVryzsndYIUQieRAn6t0=.1af94ce7-d016-44fc-8974-952fd78ca79f@github.com>
Message-ID: <8MkkDn6NoW9zqCO4Ntl62ILhOPJq45TqHB6QQFQXXJU=.9f81094c-9e59-417e-a617-3e84670eb8a9@github.com>

On Fri, 14 Feb 2025 18:22:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added copyrights
>  - replaced commens fix with supress

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23525#pullrequestreview-2624569868

From mbaesken at openjdk.org  Tue Feb 18 19:22:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Feb 2025 19:22:41 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
 <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>
Message-ID: <yUEKUpNSGMckLkdc0Q0nYZHwInQ0lX8YA-GUaTPcGgU=.51c9c748-fe5a-4066-b179-1a9ff652d97f@github.com>

On Mon, 17 Feb 2025 22:53:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get
> > 1.8M ./lib/libjdwp.debuginfo 280K ./lib/libjdwp.so
> > This looks pretty good compared to HIGH or standard (LOW/NORM) settings.
> 
> What is the optimization level?

It was with unchanged optimization settings on lib-level (so LOW/NORM stayed for libjdwp) for the compilation, but -O3 set in the linkage settings.
See the patch I used for more clarity regarding this experiment 


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index 729e508cc26..b31a98dabc0 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -537,6 +537,10 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     # no-strict-aliasing everywhere!)
     TOOLCHAIN_CFLAGS_JDK_CONLY="-fno-strict-aliasing"
 
+    # check here for opt-size setting (or later when setting)
+    TOOLCHAIN_CFLAGS_LTO_JDK="-flto=auto -fuse-linker-plugin -fno-strict-aliasing -fno-fat-lto-objects"
+    TOOLCHAIN_CXXFLAGS_LTO_JDK="-flto=auto -fuse-linker-plugin -fno-strict-aliasing -fno-fat-lto-objects"
+
   elif test "x$TOOLCHAIN_TYPE" = xclang; then
     # Restrict the debug information created by Clang to avoid
     # too big object files and speed the build up a little bit
@@ -876,9 +880,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
 
   $2CFLAGS_JDKEXE="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} $PIEFLAG"
   $2CXXFLAGS_JDKEXE="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} $PIEFLAG"
-  $2CFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} \
+  $2CFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $TOOLCHAIN_CFLAGS_LTO_JDK $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} \
       $JDK_PICFLAG ${$1_CFLAGS_CPU_JDK_LIBONLY}"
-  $2CXXFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} \
+  $2CXXFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $TOOLCHAIN_CXXFLAGS_LTO_JDK $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} \
       $JDK_PICFLAG ${$1_CFLAGS_CPU_JDK_LIBONLY}"
 
   AC_SUBST($2JVM_CFLAGS)
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index 2e060a71d4d..fbd2514ec7e 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -59,6 +59,8 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_HELPER],
         BASIC_LDFLAGS_JDK_ONLY="$BASIC_LDFLAGS_JDK_ONLY -Wl,--gc-sections"
       fi
     fi
+    # $(CXX_O_FLAG_HIGHEST_JVM) -> -O3 for gcc
+    BASIC_LDFLAGS_LTO_JDK="-O3 -flto=auto -fuse-linker-plugin -fno-strict-aliasing"
 
     BASIC_LDFLAGS_JVM_ONLY=""
 
@@ -192,7 +194,7 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
   # Export variables according to old definitions, prefix with $2 if present.
   LDFLAGS_JDK_COMMON="$BASIC_LDFLAGS $BASIC_LDFLAGS_JDK_ONLY \
       $OS_LDFLAGS $DEBUGLEVEL_LDFLAGS_JDK_ONLY ${$2EXTRA_LDFLAGS}"
-  $2LDFLAGS_JDKLIB="$LDFLAGS_JDK_COMMON \
+  $2LDFLAGS_JDKLIB="$LDFLAGS_JDK_COMMON $BASIC_LDFLAGS_LTO_JDK \
       $SHARED_LIBRARY_FLAGS $REPRODUCIBLE_LDFLAGS $FILE_MACRO_LDFLAGS"
   $2LDFLAGS_JDKEXE="$LDFLAGS_JDK_COMMON $EXECUTABLE_LDFLAGS \
       ${$1_CPU_EXECUTABLE_LDFLAGS} $REPRODUCIBLE_LDFLAGS $FILE_MACRO_LDFLAGS"

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

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

From iklam at openjdk.org  Tue Feb 18 19:27:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Feb 2025 19:27:58 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v5]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <Al3iDuJIKjmLSSrknM4oIuH3Nn31zaKbDnNZobAVins=.296102ca-09f4-445e-b9da-f8b90bcee7c5@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

  Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/81944a2e..f78354c1

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

  Stats: 137 lines in 2 files changed: 52 ins; 84 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620

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

From alanb at openjdk.org  Tue Feb 18 19:23:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Feb 2025 19:23:44 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2666321144

From lmesnik at openjdk.org  Tue Feb 18 20:09:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 18 Feb 2025 20:09:04 GMT
Subject: Integrated: 8346050: Update BuildTestLib.gmk to build whole
 testlibrary
In-Reply-To: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
References: <kdwbKRStyOpg_-VtAyiNNk2frIGcMU5AEnsip_-yI0c=.c405bc76-424f-44ea-a0ff-22a8ee0eb8fe@github.com>
Message-ID: <KEGiPZbk4O_ivd5h393BSAno9ynsj_P3PvhvlJT5UUM=.5bdf471d-fce1-4119-92ac-3fbbe99eab8f@github.com>

On Fri, 7 Feb 2025 21:15:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes.

This pull request has now been integrated.

Changeset: 62d93f2a
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62d93f2a2222a044ac4aa409efd69e776f0d43da
Stats:     21 lines in 5 files changed: 15 ins; 0 del; 6 mod

8346050: Update BuildTestLib.gmk to build whole testlibrary

Reviewed-by: weijun, ihse

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

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

From erikj at openjdk.org  Tue Feb 18 20:25:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Feb 2025 20:25:54 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>

On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

I'm not sure if this is the right way to solve this. I would really like someone more familiar with the microbenchmarks to weigh in on how this was originally meant to work.

make/test/BuildMicrobenchmark.gmk line 127:

> 125:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
> 126:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml \
> 127:             $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml

If this is the correct solution, then copying these files should be handled separately from unpacking jars, preferably using a SetupCopyFiles macro call. Something like this (untested):

$(eval $(call SetupCopyFiles, COPY_JAXP_TEST_XML, \
    DEST := $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml, \
    FILES := \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/validation/tck/reZ003vExc23082309.xml \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml, \
    FLATTEN := true, \
))

And then add $(COPY_JAXP_TEST_XML) to the list of dependencies in the `SetupJarArchive` call below.

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

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2624942656
PR Review Comment: https://git.openjdk.org/jdk/pull/23625#discussion_r1960535658

From erikj at openjdk.org  Tue Feb 18 20:30:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Feb 2025 20:30:58 GMT
Subject: RFR: 8350094: Linux gcc 13.2.0 build fails when ubsan is enabled
In-Reply-To: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
References: <dNBXzL6AKCVMuk_zsanSQSJBAAGsQidIEuHsNcnPgqA=.4328d6c5-0fdd-4bf3-b397-ef1a185d0e4f@github.com>
Message-ID: <TTlw-tPOFXp-0m48v_SyjGfsAUdVwZRsayi3jXWKJls=.7cf91b66-660b-4cf9-b295-7ff47eefd69d@github.com>

On Fri, 14 Feb 2025 15:04:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using a gcc 13.2.0 devkit, the Linux builds (x86_64 and ppc64le) fail with warnings as errors in case that ubsan is enabled.
> The 2 warnings as errors are about memset usages ; we see those issues with gcc 13.2 but did not see it with previously used gcc 11.
> They only occur with ubsan enabled (seems the warnings change a bit in this case).
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' offset [0, 7] is out of the bounds [0, 0] [-Werror=array-bounds=]
> 
> src/java.desktop/share/native/liblcms/cmsmd5.c:303:5: error: 'memset' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:144:10: error: 'memset' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object

This line is getting very long. Next time please break it up for readability.

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

PR Comment: https://git.openjdk.org/jdk/pull/23639#issuecomment-2666863222

From erikj at openjdk.org  Tue Feb 18 20:31:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Feb 2025 20:31:53 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
 <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
Message-ID: <4CNmAj_tAJjsGFcLUOes9LIDtIKET0N_7nuVh8UmIGQ=.8d970607-604e-4e8b-b4c4-0cfdf6b9565c@github.com>

On Fri, 14 Feb 2025 17:50:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.5.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>> 
>> Tested with tier 1 ? tier 8.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TEST.ROOT in `test/docs`

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2624963506

From lmesnik at openjdk.org  Tue Feb 18 20:56:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 18 Feb 2025 20:56:43 GMT
Subject: RFR: 8350280: The JDK-8346050 testlibrary changes break the build
Message-ID: <5qnBjOLWK0DPmYREq9P9DmxazOKxDzpp8JhFl9QzJRA=.814b5164-e702-434e-be65-9b53b81cfae5@github.com>

Please review following trivial PR that fix library build by adding --add-exports. 
Testing: tier1

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

Commit messages:
 - Added javac opts

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

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

From dholmes at openjdk.org  Tue Feb 18 20:56:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Feb 2025 20:56:43 GMT
Subject: RFR: 8350280: The JDK-8346050 testlibrary changes break the build
In-Reply-To: <5qnBjOLWK0DPmYREq9P9DmxazOKxDzpp8JhFl9QzJRA=.814b5164-e702-434e-be65-9b53b81cfae5@github.com>
References: <5qnBjOLWK0DPmYREq9P9DmxazOKxDzpp8JhFl9QzJRA=.814b5164-e702-434e-be65-9b53b81cfae5@github.com>
Message-ID: <-v8qdFBEOs9y-9eGhCDfwhL-Nh3qFvzTxmSSRFRyT48=.af6c3b27-dd2a-4266-b3ed-ff8dd7c1d579@github.com>

On Tue, 18 Feb 2025 20:49:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following trivial PR that fix library build by adding --add-exports. 
> Testing: tier1

Seems reasonable - and trivial

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23680#pullrequestreview-2625003359

From erikj at openjdk.org  Tue Feb 18 20:56:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Feb 2025 20:56:56 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG_AOT_JDK=true" [v5]
In-Reply-To: <Al3iDuJIKjmLSSrknM4oIuH3Nn31zaKbDnNZobAVins=.296102ca-09f4-445e-b9da-f8b90bcee7c5@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <Al3iDuJIKjmLSSrknM4oIuH3Nn31zaKbDnNZobAVins=.296102ca-09f4-445e-b9da-f8b90bcee7c5@github.com>
Message-ID: <wWK36IHXb-PS3VU7DHv4zQu_pjKJPhMbN-QYi7tSi0c=.dee261d8-13dd-4f1e-8c04-6065398fa28b@github.com>

On Tue, 18 Feb 2025 19:27:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When running HotSpot jtreg tests in the "AOT mode", for example:
>> 
>> 
>> make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
>> 
>> 
>> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
>> 
>> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
>> 
>> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
>> 
>> ** Changes in this PR **
>> 
>> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file

Thank you for helping cleaning this up and moving the compilation of the tool to build time and the test image. Added some more comments.

make/Main.gmk line 757:

> 755: 
> 756: $(eval $(call SetupTarget, build-test-setup-aot, \
> 757:     MAKEFILE := test/BuildJtregSetupAOT, \

Maybe name the file to match the target (i.e. BuildTestSetupAot)? I don't think there is anything actually jtreg specific about this AOT tool we are building, is there?

make/Main.gmk line 758:

> 756: $(eval $(call SetupTarget, build-test-setup-aot, \
> 757:     MAKEFILE := test/BuildJtregSetupAOT, \
> 758:     DEPS := interim-langtools exploded-image build-test-lib, \

I don't think `build-test-lib` is needed.

make/PreInitSupport.gmk line 46:

> 44: # All known make control variables; these are handled in other makefiles
> 45: MAKE_CONTROL_VARIABLES += JDK_FILTER SPEC_FILTER \
> 46:     TEST TEST_JOBS JTREG JTREG_AOT_JDK GTEST MICRO TEST_OPTS TEST_VM_OPTS TEST_DEPS

This isn't how this filter is meant to be used. `JTREG_AOT_JDK` is the internal representation of setting `JTREG=AOT_JDK=...` on the make command line. While it is technically possible to directly set the internal variable, the intended way of setting this is through the `JTREG` control variable. This gives us the ability to validate the input to reduce the chance of typos messing up a test run. So `JTREG_AOT_JDK` should not be added here as we want to be warned when someone uses the internal form.

make/test/BuildJtregSetupAOT.gmk line 29:

> 27: 
> 28: include $(SPEC)
> 29: include MakeBase.gmk

This should be replaced with just `include MakeFileStart.gmk` since [JDK-8349515](https://bugs.openjdk.org/browse/JDK-8349515), and the file should end with `include MakeFileEnd.gmk`. This will declare `all` as the default target and declare `all: $(TARGETS)` at the bottom. You will need to retain the `images` target and the `.PHONY` declaration for `images`.

make/test/BuildJtregSetupAOT.gmk line 41:

> 39: SETUP_AOT_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/jtreg_setup_aot
> 40: SETUP_AOT_JAR     := $(SETUP_AOT_SUPPORT)/jtregSetupAOT.jar
> 41: SETUP_AOT_CLASS   := $(SETUP_AOT_SUPPORT)/classes/ExerciseJDKClasses.class

We do not encourage aligning assignments like this in the makefiles.
https://openjdk.org/groups/build/doc/code-conventions.html

make/test/BuildJtregSetupAOT.gmk line 47:

> 45:     SRC := $(SETUP_AOT_BASEDIR), \
> 46:     BIN := $(SETUP_AOT_SUPPORT)/classes, \
> 47:     JAR := $(SETUP_AOT_JAR), \

If we aren't using the jar, no need to build it.

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

PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2624978833
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960561460
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960572020
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960558691
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960566324
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960567801
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960569143

From lmesnik at openjdk.org  Tue Feb 18 21:00:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 18 Feb 2025 21:00:55 GMT
Subject: Integrated: 8350280: The JDK-8346050 testlibrary changes break the
 build
In-Reply-To: <5qnBjOLWK0DPmYREq9P9DmxazOKxDzpp8JhFl9QzJRA=.814b5164-e702-434e-be65-9b53b81cfae5@github.com>
References: <5qnBjOLWK0DPmYREq9P9DmxazOKxDzpp8JhFl9QzJRA=.814b5164-e702-434e-be65-9b53b81cfae5@github.com>
Message-ID: <QHw_bCXAe6tmllC_NSvu7421PMD8L8ubgHVYNiRAr5Q=.a35b082b-e701-42a0-9d91-b4e280818b6c@github.com>

On Tue, 18 Feb 2025 20:49:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following trivial PR that fix library build by adding --add-exports. 
> Testing: tier1

This pull request has now been integrated.

Changeset: 2d03bd00
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d03bd007895b139b027947852c8b5ad8eab49b6
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8350280: The JDK-8346050 testlibrary changes break the build

Reviewed-by: dholmes

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

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

From jiangli at openjdk.org  Tue Feb 18 21:29:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 21:29:52 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>
Message-ID: <lorIpSLqQ937bakcDSCAnkJyGGeCAQ9HVOnXYZ_hEQo=.5f848525-7d25-4bbc-bec2-217ea424b069@github.com>

On Tue, 18 Feb 2025 17:05:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.

Thanks, @AlanBateman. I think skipping this test for static JDK sounds reasonable to me, since this test seems to explicitly test these JNU_ functions. Changing to do dynamic lookup may alter the original intention. I'll update after https://github.com/openjdk/jdk/pull/23528.

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

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2666964844

From imyers at openjdk.org  Tue Feb 18 23:08:57 2025
From: imyers at openjdk.org (Ian Myers)
Date: Tue, 18 Feb 2025 23:08:57 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
Message-ID: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>

On Wed, 29 Jan 2025 23:15:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
>> 
>> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
>> 
>> - Contacted ietf, these are the new links to use.
>> 
>> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
>> 
>> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.
>
> make/common/Modules.gmk line 95:
> 
>> 93: SPEC_SUBDIRS += share/specs
>> 94: 
>> 95: MAN_SUBDIRS += share/man windows/man
> 
> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.

Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1960715214

From jiangli at openjdk.org  Tue Feb 18 23:52:05 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 23:52:05 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <kxQzrvmfkQ2M_FtJwRIcUQmNgi7mJsW1illNB56bwwc=.5d784866-3931-4b69-bebd-58f878bf063e@github.com>

On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

I brought up this PR during today's hermetic Java meeting. There was a question asked about the time used for the static build job. Here is a comparison between `linux-x64-static` and existing `linux-x64` jobs in GHA:

- [linux-x64-static / build (release)](https://github.com/jianglizhou/jdk/actions/runs/13163673020/job/36738564072#logs): 29m 29s
- [linux-x64 / build (release)](https://github.com/jianglizhou/jdk/actions/runs/13163673020/job/36738560475#logs): 35m 16s

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2667177994

From iklam at openjdk.org  Wed Feb 19 00:27:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Feb 2025 00:27:17 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v6]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <vW_4oucjmwHWRRMLFIrlLMXBLXtqezD1PZNs10Qhqzg=.c9645ac8-4030-47b6-8a0a-04a532d335a4@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

  Review comments from @erikj79

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/f78354c1..b5ccc05d

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

  Stats: 157 lines in 6 files changed: 70 ins; 68 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23620/head:pull/23620

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

From iklam at openjdk.org  Wed Feb 19 00:32:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Feb 2025 00:32:55 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v5]
In-Reply-To: <wWK36IHXb-PS3VU7DHv4zQu_pjKJPhMbN-QYi7tSi0c=.dee261d8-13dd-4f1e-8c04-6065398fa28b@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <Al3iDuJIKjmLSSrknM4oIuH3Nn31zaKbDnNZobAVins=.296102ca-09f4-445e-b9da-f8b90bcee7c5@github.com>
 <wWK36IHXb-PS3VU7DHv4zQu_pjKJPhMbN-QYi7tSi0c=.dee261d8-13dd-4f1e-8c04-6065398fa28b@github.com>
Message-ID: <w3HnIdw5xI5-TvHGFGslHpdsXZGr7Wy0OKxFz8MPrug=.f0bf3e67-ad27-4eeb-ac4b-7902457a756b@github.com>

On Tue, 18 Feb 2025 20:40:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not necessary to have the definitions in a stand-alone file
>
> make/Main.gmk line 757:
> 
>> 755: 
>> 756: $(eval $(call SetupTarget, build-test-setup-aot, \
>> 757:     MAKEFILE := test/BuildJtregSetupAOT, \
> 
> Maybe name the file to match the target (i.e. BuildTestSetupAot)? I don't think there is anything actually jtreg specific about this AOT tool we are building, is there?

I renamed the file to `BuildTestSetupAOT.gmk`. I also changed the `SetupAot` function to `SetupAOT` (the convention we have been following for the rest of the code has been to use either `AOT` or `aot`, but not `Aot`.).

> make/Main.gmk line 758:
> 
>> 756: $(eval $(call SetupTarget, build-test-setup-aot, \
>> 757:     MAKEFILE := test/BuildJtregSetupAOT, \
>> 758:     DEPS := interim-langtools exploded-image build-test-lib, \
> 
> I don't think `build-test-lib` is needed.

Removed.

> make/PreInitSupport.gmk line 46:
> 
>> 44: # All known make control variables; these are handled in other makefiles
>> 45: MAKE_CONTROL_VARIABLES += JDK_FILTER SPEC_FILTER \
>> 46:     TEST TEST_JOBS JTREG JTREG_AOT_JDK GTEST MICRO TEST_OPTS TEST_VM_OPTS TEST_DEPS
> 
> This isn't how this filter is meant to be used. `JTREG_AOT_JDK` is the internal representation of setting `JTREG=AOT_JDK=...` on the make command line. While it is technically possible to directly set the internal variable, the intended way of setting this is through the `JTREG` control variable. This gives us the ability to validate the input to reduce the chance of typos messing up a test run. So `JTREG_AOT_JDK` should not be added here as we want to be warned when someone uses the internal form.

Fixed.

> make/test/BuildJtregSetupAOT.gmk line 29:
> 
>> 27: 
>> 28: include $(SPEC)
>> 29: include MakeBase.gmk
> 
> This should be replaced with just `include MakeFileStart.gmk` since [JDK-8349515](https://bugs.openjdk.org/browse/JDK-8349515), and the file should end with `include MakeFileEnd.gmk`. This will declare `all` as the default target and declare `all: $(TARGETS)` at the bottom. You will need to retain the `images` target and the `.PHONY` declaration for `images`.

I updated the file using the same format as the existing BuildJtregTestThreadFactory.gmk file. Could you check if I missed anything?

> make/test/BuildJtregSetupAOT.gmk line 41:
> 
>> 39: SETUP_AOT_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/jtreg_setup_aot
>> 40: SETUP_AOT_JAR     := $(SETUP_AOT_SUPPORT)/jtregSetupAOT.jar
>> 41: SETUP_AOT_CLASS   := $(SETUP_AOT_SUPPORT)/classes/ExerciseJDKClasses.class
> 
> We do not encourage aligning assignments like this in the makefiles.
> https://openjdk.org/groups/build/doc/code-conventions.html

Fixed. I also fixed other places where we had such alignments.

> make/test/BuildJtregSetupAOT.gmk line 47:
> 
>> 45:     SRC := $(SETUP_AOT_BASEDIR), \
>> 46:     BIN := $(SETUP_AOT_SUPPORT)/classes, \
>> 47:     JAR := $(SETUP_AOT_JAR), \
> 
> If we aren't using the jar, no need to build it.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776675
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776539
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776731
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776643
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776608
PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1960776564

From syan at openjdk.org  Wed Feb 19 01:56:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 01:56:52 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
Message-ID: <3AN5Fwk8TfNv_1V-7E7W-t6Q8qe92s7wyr8ZZSmq2G0=.bccb9375-93ed-4b8e-8e2a-86c1cc4e7a4a@github.com>

On Tue, 18 Feb 2025 20:23:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm not sure if this is the right way to solve this. I would really like someone more familiar with the microbenchmarks to weigh in on how this was originally meant to work.

Hi, @cl4es, Could you take took this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667323936

From jpai at openjdk.org  Wed Feb 19 02:10:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Feb 2025 02:10:58 GMT
Subject: RFR: 8339238: Update to use jtreg 7.5.1 [v2]
In-Reply-To: <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
 <IOg1Qls3ms1CnJTn_GNYKM1iR6OfLTfXgNh6JglxHfg=.69ca0ba0-c6ba-4f1b-9bfd-c336352791a9@github.com>
Message-ID: <CQ37RxpOCdg8JIegy2CV2M245A-cNeIg7YxCQsL8pDA=.fce1b523-365b-4451-a4e2-5a50cad51001@github.com>

On Fri, 14 Feb 2025 17:50:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.5.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
>> 
>> Tested with tier 1 ? tier 8.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TEST.ROOT in `test/docs`

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20766#pullrequestreview-2625464354

From syan at openjdk.org  Wed Feb 19 03:21:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 03:21:37 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

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

  Use SetupCopyFiles macro to copy the dependency files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23625/files
  - new: https://git.openjdk.org/jdk/pull/23625/files/ba555448..f553bf77

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

  Stats: 17 lines in 1 file changed: 11 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23625/head:pull/23625

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

From syan at openjdk.org  Wed Feb 19 03:25:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 03:25:01 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
Message-ID: <XLIwiLDEeKWSyctkgPl4NiLli-vthEmxbAZPQG82d2I=.301b05c8-3228-4bd6-8e35-f31d6b4dec6d@github.com>

On Tue, 18 Feb 2025 20:18:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SetupCopyFiles macro to copy the dependency files
>
> make/test/BuildMicrobenchmark.gmk line 127:
> 
>> 125:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
>> 126:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml \
>> 127:             $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml
> 
> If this is the correct solution, then copying these files should be handled separately from unpacking jars, preferably using a SetupCopyFiles macro call. Something like this (untested):
> 
> $(eval $(call SetupCopyFiles, COPY_JAXP_TEST_XML, \
>     DEST := $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml, \
>     FILES := \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/validation/tck/reZ003vExc23082309.xml \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml, \
>     FLATTEN := true, \
> ))
> 
> And then add $(COPY_JAXP_TEST_XML) to the list of dependencies in the `SetupJarArchive` call below.

The `SetupCopyFiles` macro seems do not support multiple absolute path `FILES` arguments, so I use relative path instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23625#discussion_r1960893035

From redestad at openjdk.org  Wed Feb 19 05:07:52 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 05:07:52 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

The issue here looks like an oversight (of mine) in the migration from the standalone JMH repo. There we simply held a copy of the needed XML files, e.g. https://github.com/openjdk/jmh-jdk-microbenchmarks/blob/master/micros-jdk8/src/main/resources/org/openjdk/bench/javax/xml/msgAttach.xml

As we're now in-tree I guess it makes sense to copy these over at build time as per this fix - though it creates an undocumented dependency. If anyone changes these tests on the functional side we'd silently break. Perhaps needs a unit test to guard and document the dependency?

Taking a step back: If these particular micros have all been broken since JEP 230 was integrated in JDK 12 and no-one noticed until now - maybe they aren't really worth their weight and should instead be removed?

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667518427

From cstein at openjdk.org  Wed Feb 19 06:40:58 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 19 Feb 2025 06:40:58 GMT
Subject: Integrated: 8339238: Update to use jtreg 7.5.1
In-Reply-To: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
References: <9h4THKlDG9foumtc4Ii3ZuvZaumzIt_dzaHfp1ydzXM=.ca123dd0-8328-4761-9a82-4198ec653645@github.com>
Message-ID: <z0iMSCHtYQ9RKOKA9di3SNRpx5TGRz1QH8kfsvzpNcw=.9e311259-cd85-495f-acd4-038362c1ef24@github.com>

On Thu, 29 Aug 2024 11:26:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 9042aa82
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9042aa82a890b0f0348ac8127dbd3268f2620346
Stats:     14 lines in 9 files changed: 0 ins; 0 del; 14 mod

8339238: Update to use jtreg 7.5.1

Reviewed-by: erikj, jpai, rriggs, iris

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

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

From syan at openjdk.org  Wed Feb 19 07:07:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 07:07:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>
Message-ID: <yIvILphjOebjUcqXe-u-sMJd60FKYfFQ1zDL5Pl2Z4s=.d74931fc-728a-4be0-8c5e-079657f053b1@github.com>

On Wed, 19 Feb 2025 05:05:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> If anyone changes these tests on the functional side we'd silently break.

After this PR, if the dependency XML files been removed will make `make test-image` fails. So maybe we do not need a new unit test to guard it.

> Perhaps needs a unit test to guard and document the dependency?

Where should I document the dependency, does anyone could give some suggestions. OTOH maybe we should remove this JMH test?

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667685552

From redestad at openjdk.org  Wed Feb 19 08:04:53 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 08:04:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

If you have manually verified that the build fails if any of these files are removed then I'm happy. No new tests or documentation needed, really. 

I could cast my vote towards removing these particular micros. But as the work is done I say let's accept your change, (re-)evaluate their usefulness, and file a RFE to have them removed if they aren't. We have been building out the set of micros we regularly test in nightly / promotion testing, but due to resource constraints only a fraction is run on a regular basis - and javax.xml has not been a priority.

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667842084

From syan at openjdk.org  Wed Feb 19 08:51:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 08:51:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
Message-ID: <W-hxtaAW4Ysb4I5jQ87eTGBphlCdPe9X4S_6ePm1G-E=.25bacaec-1899-4b21-8e18-fb34b9815847@github.com>

On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> have manually verified that the build fails if any of these files are removed.

Yes. I have verified that. If I remove the dependency XML file, then `make test-image CONF=release JOBS=1` will report below failure.


gmake[3]: *** No rule to make target '/home/yansendao/git/jdk-ysd/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml', needed by '/home/yansendao/git/jdk-ysd/build/linux-x86_64-server-release/support/test/micro/classes/org/openjdk/bench/javax/xml/message_12.xml'.  Stop.
gmake[2]: *** [make/Main.gmk:788: build-microbenchmark] Error 2

ERROR: Build failed for target 'test-image' in configuration 'linux-x86_64-server-release' (exit code 2)

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667943440

From duke at openjdk.org  Wed Feb 19 09:55:42 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Wed, 19 Feb 2025 09:55:42 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
Message-ID: <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>

> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
> 
> Use the additional information in the "summary" block printed at the end of `make test` target.

Ivan Bereziuk 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 11 additional commits since the last revision:

 - Merge branch 'master' into 8343832_enhance_test_summary
 - Merge branch 'master' into 8343832_enhance_test_summary
 - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
 - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
 - adapt changes to the ancient awk on MacOS
 - Merge branch 'master' into 8343832_enhance_test_summary
 - indented the comment
 - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
 - lowercased Jtreg. fixed typos in the comment
 - aggregated calculation for many categoires of skipped tests into one gawk block with regex
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ba2b0c2b...6af586a2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22245/files
  - new: https://git.openjdk.org/jdk/pull/22245/files/4a1a9268..6af586a2

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

  Stats: 212999 lines in 5143 files changed: 102946 ins; 87626 del; 22427 mod
  Patch: https://git.openjdk.org/jdk/pull/22245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22245/head:pull/22245

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

From duke at openjdk.org  Wed Feb 19 10:01:58 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Wed, 19 Feb 2025 10:01:58 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
Message-ID: <GYRhuN82rW3FrTA8UQCdiGIEmi5qV9lYUcPqeB9pneI=.225149e1-063f-4d94-86d4-a2175891bcaa@github.com>

On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>  - adapt changes to the ancient awk on MacOS
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - indented the comment
>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>  - lowercased Jtreg. fixed typos in the comment
>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/20b954b7...6af586a2

JDK moved to the newer JTREG 7.5.1 - https://bugs.openjdk.org/browse/JDK-8339238.
I merged the branch with `master`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22245#issuecomment-2668129982

From nbenalla at openjdk.org  Wed Feb 19 11:05:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 11:05:59 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
 <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
Message-ID: <HX3zhtWYlzDwcThjfRfh2UiSgtjvxOyz3lHTM4rr3cw=.98597d31-7abe-40a2-b7bf-36b592597b34@github.com>

On Tue, 18 Feb 2025 23:06:42 GMT, Ian Myers <imyers at openjdk.org> wrote:

>> make/common/Modules.gmk line 95:
>> 
>>> 93: SPEC_SUBDIRS += share/specs
>>> 94: 
>>> 95: MAN_SUBDIRS += share/man windows/man
>> 
>> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.
>
> Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

I think it will prevent windows-only tools man pages from being generated in linux builds, but it would prevent the man pages from appearing in the generated documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1961472101

From erikj at openjdk.org  Wed Feb 19 13:49:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 13:49:58 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <y6d6_b60b9nidZHhFWe-z9fErOcE0edW2TriTlORllI=.017268bc-2de1-4ee1-b579-74517baba975@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2626861253

From erikj at openjdk.org  Wed Feb 19 14:26:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 14:26:56 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v6]
In-Reply-To: <vW_4oucjmwHWRRMLFIrlLMXBLXtqezD1PZNs10Qhqzg=.c9645ac8-4030-47b6-8a0a-04a532d335a4@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <vW_4oucjmwHWRRMLFIrlLMXBLXtqezD1PZNs10Qhqzg=.c9645ac8-4030-47b6-8a0a-04a532d335a4@github.com>
Message-ID: <aywn1GG4qyxflHVLU13oSpf1C1R3M5vBUt6th1ja7Mk=.b3218dfd-42e0-4e8e-9415-cd1937a582ac@github.com>

On Wed, 19 Feb 2025 00:27:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When running HotSpot jtreg tests in the "AOT mode", for example:
>> 
>> 
>> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
>> 
>> 
>> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
>> 
>> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
>> 
>> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
>> 
>> ** Changes in this PR **
>> 
>> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from @erikj79

make/test/BuildTestSetupAOT.gmk line 63:

> 61: IMAGES_TARGETS += $(COPY_SETUP_AOT)
> 62: 
> 63: build: $(TARGETS)

The target `build` is no longer the default target in this makefile, so this line is dead code unless you change the call in Main.gmk by setting `TARGET := build`. You can also just remove this line as the default target `all` gets setup to depend on `$(TARGETS)` anyway in MakeFileEnd.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1961773716

From erikj at openjdk.org  Wed Feb 19 14:28:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 14:28:02 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
Message-ID: <gP5igOvuFLGr-BT4fYb6shmkFjZpC8JLEpllfiyQdR8=.2d356583-c3b0-48e1-a662-e58141b90bbc@github.com>

On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>  - adapt changes to the ancient awk on MacOS
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - indented the comment
>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>  - lowercased Jtreg. fixed typos in the comment
>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/de9059cd...6af586a2

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22245#pullrequestreview-2626985663

From nbenalla at openjdk.org  Wed Feb 19 15:14:28 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 15:14:28 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools
Message-ID: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>

This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds

The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195

I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.

This patch will need to be backported to JDK 24.

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

Commit messages:
 - separate man page generation on UNIX systems and man page generation for JD

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

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

From mbaesken at openjdk.org  Wed Feb 19 15:19:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Feb 2025 15:19:25 GMT
Subject: RFR: 8350267: Set mtune and mcpu settings in JDK native lib
 compilation on Linux ppc64(le)
Message-ID: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>

Currently we only set mcpu/mtune for hotspot; this might be a little problematic because other options might be used in the jdk native libs compilation .
Those other (compared to hotspot) options are defined by the gcc - version used in the build process.
'gcc -c -Q --help=target'  shows these options, they can vary depending on gcc version and build environment.

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

Commit messages:
 - JDK-8350267

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

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

From erikj at openjdk.org  Wed Feb 19 15:21:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 15:21:52 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools
In-Reply-To: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
Message-ID: <nq48YDyFKm3O4fvD_GIMN7xNdhvQGV4Br6kb80NYqOs=.e0ae6462-3312-4451-8e88-faba232b7fd9@github.com>

On Wed, 19 Feb 2025 14:34:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds
> 
> The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195
> 
> I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.
> 
> This patch will need to be backported to JDK 24.

make/common/Modules.gmk line 92:

> 90: MAN_SUBDIRS += share/man $(TARGET_OS)/man
> 91: 
> 92: MAN_DOCS_SUBDIRS += share/man windows/man

I think this warrants a comment explaining why we need a separate list.
Suggestion:

# The docs should include the sum of all man pages for all platforms
MAN_DOCS_SUBDIRS += share/man windows/man

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23697#discussion_r1961878087

From mbaesken at openjdk.org  Wed Feb 19 15:29:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Feb 2025 15:29:52 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: <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@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 .

So what's the opinion, should we go for SIZE optimization for libjdwp?
My idea was that the current setting LOW indicates that the lib is not super performance critical; so SIZE might be a nice option ?

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

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

From mdoerr at openjdk.org  Wed Feb 19 16:04:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Feb 2025 16:04:55 GMT
Subject: RFR: 8350267: Set mtune and mcpu settings in JDK native lib
 compilation on Linux ppc64(le)
In-Reply-To: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
References: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
Message-ID: <Y33yQttvTqvKpmpxCH-Ru74UG_NJvY1zZaTUS5pSC_0=.2a797a57-c8d0-4e66-9379-ba54aaed0aed@github.com>

On Wed, 19 Feb 2025 15:13:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we only set mcpu/mtune for hotspot; this might be a little problematic because other options might be used in the jdk native libs compilation .
> Those other (compared to hotspot) options are defined by the gcc - version used in the build process.
> 'gcc -c -Q --help=target'  shows these options, they can vary depending on gcc version and build environment.

LGTM. Thanks for cleaning this up!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23698#pullrequestreview-2627291073

From nbenalla at openjdk.org  Wed Feb 19 16:05:15 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 16:05:15 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools [v2]
In-Reply-To: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
Message-ID: <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>

> This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds
> 
> The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195
> 
> I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.
> 
> This patch will need to be backported to JDK 24.

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

  respond to feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23697/files
  - new: https://git.openjdk.org/jdk/pull/23697/files/ae7fbae6..6b5f20ae

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

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

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

From asteiner at openjdk.org  Wed Feb 19 16:32:51 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Wed, 19 Feb 2025 16:32:51 GMT
Subject: RFR: 8350267: Set mtune and mcpu settings in JDK native lib
 compilation on Linux ppc64(le)
In-Reply-To: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
References: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
Message-ID: <OZn7MezgD9VfsWYcqY_wsW51TG7YJkh-F_b0IgyydQg=.40ea24e9-ecf3-44a2-956b-01e361f87d5e@github.com>

On Wed, 19 Feb 2025 15:13:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we only set mcpu/mtune for hotspot; this might be a little problematic because other options might be used in the jdk native libs compilation .
> Those other (compared to hotspot) options are defined by the gcc - version used in the build process.
> 'gcc -c -Q --help=target'  shows these options, they can vary depending on gcc version and build environment.

LGTM

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

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/23698#pullrequestreview-2627368588

From cjplummer at openjdk.org  Wed Feb 19 17:16:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 17:16:59 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
Message-ID: <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>

On Wed, 19 Feb 2025 15:27:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So what's the opinion, should we go for SIZE optimization for libjdwp?
> My idea was that the current setting LOW indicates that the lib is not super performance critical; so SIZE might be a nice option ?

I'm not sure how the decision was made to go with LOW for libjdwp. Much of what it does is transactional over the wire, so probably not subject much to code performance, but there are some more heavyweight tasks that the debug agent needs to do, especially when dealing with a a large number of threads. I'd like to see those tasks sped up if anything.

It seems LTO would be good to enable regardless of the optimization level. One thing you haven't given numbers for is LTO+HIGH. Based on the other results so far, seems the footprint would be slightly below to the current LOW setting (maybe 3-4k).

When faced with a decision like this that doesn't have concrete data as to what the right choice is, I'd tend to go with the status quo and make no change, although it seems going with LTO should be a good choice no matter the opt level unless there is some other possible negative side affect of doing so that hasn't been brought up.

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

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

From erikj at openjdk.org  Wed Feb 19 17:43:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 17:43:54 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools [v2]
In-Reply-To: <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
 <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>
Message-ID: <yHKAzec7chhzKtICRf0rhBHQjyGOGu_RrRgLAKaVB6A=.fa6b3222-caf9-4c4e-be3a-f0fe1edd1a1d@github.com>

On Wed, 19 Feb 2025 16:05:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds
>> 
>> The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195
>> 
>> I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.
>> 
>> This patch will need to be backported to JDK 24.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   respond to feedback

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23697#pullrequestreview-2627542351

From erikj at openjdk.org  Wed Feb 19 17:44:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 17:44:56 GMT
Subject: RFR: 8350267: Set mtune and mcpu settings in JDK native lib
 compilation on Linux ppc64(le)
In-Reply-To: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
References: <OQ6Ko6SURdGFzzoH1E00VgPDcwkxGbe7llp2SBT92LA=.d778918e-fcf9-44e8-9bd5-915e50767662@github.com>
Message-ID: <gTmgKF_iTizux0Q90B0NoQ1Swj5xAwor7FLlIx8hP-g=.de2ad953-7d90-4a01-a6df-f0fbe731e5ab@github.com>

On Wed, 19 Feb 2025 15:13:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we only set mcpu/mtune for hotspot; this might be a little problematic because other options might be used in the jdk native libs compilation .
> Those other (compared to hotspot) options are defined by the gcc - version used in the build process.
> 'gcc -c -Q --help=target'  shows these options, they can vary depending on gcc version and build environment.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23698#pullrequestreview-2627544906

From redestad at openjdk.org  Wed Feb 19 19:16:53 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 19:16:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <EAEam6h8Ud94rHZX9d9iFIBAAeUlvH8bt4dzBuuUsqA=.4738f6fd-29ae-4e68-bd00-99d5ac58d520@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2627748496

From iklam at openjdk.org  Wed Feb 19 19:20:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Feb 2025 19:20:13 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v7]
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

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

  Review comments from @erikj79

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23620/files
  - new: https://git.openjdk.org/jdk/pull/23620/files/b5ccc05d..3d25d75a

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

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

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

From iklam at openjdk.org  Wed Feb 19 19:20:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Feb 2025 19:20:13 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v6]
In-Reply-To: <aywn1GG4qyxflHVLU13oSpf1C1R3M5vBUt6th1ja7Mk=.b3218dfd-42e0-4e8e-9415-cd1937a582ac@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <vW_4oucjmwHWRRMLFIrlLMXBLXtqezD1PZNs10Qhqzg=.c9645ac8-4030-47b6-8a0a-04a532d335a4@github.com>
 <aywn1GG4qyxflHVLU13oSpf1C1R3M5vBUt6th1ja7Mk=.b3218dfd-42e0-4e8e-9415-cd1937a582ac@github.com>
Message-ID: <W9Z6VhC18dfwnJTtMsNk6o6TkXjjA7Bo4YFV6I1K5Dc=.564cc232-7830-4421-b797-0106c0f8a5cc@github.com>

On Wed, 19 Feb 2025 14:21:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from @erikj79
>
> make/test/BuildTestSetupAOT.gmk line 63:
> 
>> 61: IMAGES_TARGETS += $(COPY_SETUP_AOT)
>> 62: 
>> 63: build: $(TARGETS)
> 
> The target `build` is no longer the default target in this makefile, so this line is dead code unless you change the call in Main.gmk by setting `TARGET := build`. You can also just remove this line as the default target `all` gets setup to depend on `$(TARGETS)` anyway in MakeFileEnd.gmk.

I removed this line and verified TestSetupAOT.class is still created inside the test image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23620#discussion_r1962240880

From erikj at openjdk.org  Wed Feb 19 21:03:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 21:03:54 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v7]
In-Reply-To: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>
Message-ID: <wIAsZb34TQBk9gFoU1mcgSQ7_X-yKgnzjU_XSLZU6gI=.4e0af340-017d-4075-8b84-28a604b3ed02@github.com>

On Wed, 19 Feb 2025 19:20:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When running HotSpot jtreg tests in the "AOT mode", for example:
>> 
>> 
>> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
>> 
>> 
>> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
>> 
>> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
>> 
>> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
>> 
>> ** Changes in this PR **
>> 
>> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from @erikj79

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2627971059

From ccheung at openjdk.org  Wed Feb 19 23:45:54 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Feb 2025 23:45:54 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v7]
In-Reply-To: <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>
Message-ID: <k8-fUByNFykffYAMLhiT7vyPCGe4zjNdtz9eCOwWUE4=.07757cd9-7fca-4707-8933-0dbaacf856ac@github.com>

On Wed, 19 Feb 2025 19:20:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> When running HotSpot jtreg tests in the "AOT mode", for example:
>> 
>> 
>> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
>> 
>> 
>> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
>> 
>> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
>> 
>> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
>> 
>> ** Changes in this PR **
>> 
>> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from @erikj79

Hotspot changes look good.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23620#pullrequestreview-2628228204

From iklam at openjdk.org  Thu Feb 20 02:16:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Feb 2025 02:16:00 GMT
Subject: RFR: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true" [v7]
In-Reply-To: <wIAsZb34TQBk9gFoU1mcgSQ7_X-yKgnzjU_XSLZU6gI=.4e0af340-017d-4075-8b84-28a604b3ed02@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
 <5dJ9AtxmzatcnCW47euPxY-m1PzxPFO6QyJ5y8_Ja8Q=.1e2435c5-e04f-4eb9-af3b-2e2adafc0cb5@github.com>
 <wIAsZb34TQBk9gFoU1mcgSQ7_X-yKgnzjU_XSLZU6gI=.4e0af340-017d-4075-8b84-28a604b3ed02@github.com>
Message-ID: <AV2Cz2z4V1glxXBf4qtd7Ugk9j8Krtkqpndz3nGaNFM=.5425719a-aa8b-44c8-8211-ed75cd817479@github.com>

On Wed, 19 Feb 2025 21:01:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from @erikj79
>
> Marked as reviewed by erikj (Reviewer).

Thanks @erikj79 @calvinccheung for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23620#issuecomment-2670294223

From iklam at openjdk.org  Thu Feb 20 02:16:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Feb 2025 02:16:02 GMT
Subject: Integrated: 8349953: Avoid editing AOTConfiguration file in
 "make test JTREG=AOT_JDK=true"
In-Reply-To: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
References: <lN8BhBX_ari2bkJtqWsVswvvmYXBozzTTMaCaAJyVLA=.d46827ea-755c-4e73-8b21-60c2316a86d1@github.com>
Message-ID: <YAlNz9mwC27AMuaHxAw1aTmhwP2zHTppa5DxkMpIbF8=.f12baf23-20a8-4a60-ad15-f4e1cfaf5d8a@github.com>

On Thu, 13 Feb 2025 17:45:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When running HotSpot jtreg tests in the "AOT mode", for example:
> 
> 
> make test JTREG=AOT_JDK=true TEST=open/test/hotspot/jtreg/runtime/stringtable
> 
> 
> Before this PR, in the test set up phase, we record several AOT configuration files by running a few separate Java tools (javac, javap, jlink, and jar), and then combine them together with sed, grep, sort and uniq:
> 
> https://github.com/openjdk/jdk/blob/adc3f53d2403cd414a91e71c079b4108b2346da0/make/RunTests.gmk#L723-L744
> 
> After [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), the AOT configuration file will change to a binary format and can no longer be edited this way. In preparation for [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), we should change the "JTREG_AOT_JDK=true" set up to run a single Java program that accomplishes the same effect as the current implementation.
> 
> ** Changes in this PR **
> 
> This PR combines the invocation of these Java tools into a single Java program, so we just have a single AOT configuration file. It also uses the `-XX:ExtraSharedClassListFile` option to include the default classlist from the JDK home directory,

This pull request has now been integrated.

Changeset: 0131c1bf
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0131c1bfd8ccfdf4f3d73cddfc2a87e2a6e99581
Stats:     194 lines in 5 files changed: 158 ins; 18 del; 18 mod

8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true"

Reviewed-by: erikj, ccheung

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

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

From syan at openjdk.org  Thu Feb 20 02:53:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 02:53:58 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
Message-ID: <1YbF0N2tyvKhm0l0X_BJQZogUfuA1ne7Wfs1n3MYP7I=.5ab9a5b3-7342-4fb1-a151-b5d27a67e4bb@github.com>

On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SetupCopyFiles macro to copy the dependency files
>
> If you have manually verified that the build fails if any of these files are removed then I'm happy. No new tests or documentation needed, really. 
> 
> I could cast my vote towards removing these particular micros. But as the work is done I say let's accept your change, (re-)evaluate their usefulness, and file a RFE to have them removed if they aren't. We have been building out the set of micros we regularly test in nightly / promotion testing, but due to resource constraints only a fraction is run on a regular basis - and javax.xml has not been a priority.

Thanks @cl4es @erikj79 for the suggestions and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2670335704

From syan at openjdk.org  Thu Feb 20 02:53:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 02:53:59 GMT
Subject: Integrated: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <jGmCMSdLG_kmg1XqJ4TR-rJWSNQLxRf9BNYUCDgpBM8=.71901ddd-4992-4576-b8bd-94a5cb99247f@github.com>

On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

This pull request has now been integrated.

Changeset: 00d4e4a9
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00d4e4a9710f89506f36156c24b0f3c5412971fa
Stats:     16 lines in 2 files changed: 11 ins; 2 del; 3 mod

8350051: [JMH] Several tests fails NPE

Reviewed-by: erikj, redestad

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

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

From mbaesken at openjdk.org  Thu Feb 20 13:35:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Feb 2025 13:35:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
 <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>
Message-ID: <vRuYr-EclorQhOF0Np8HiABIMiCMf3xNWzOIDT9FSjE=.b05a9c6b-7930-4d19-8b1c-34923b8699b0@github.com>

On Wed, 19 Feb 2025 17:12:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not sure how the decision was made to go with LOW for libjdwp. 

>From what I heard from Magnus, those settings were done ages ago , before recent compiler switches and even before the current build system was introduced.

We switched in the meantime from gcc 11.3 to gcc 13.2 in our buildenv .
libjdwp.so / debuginfo is  with opt
SIZE -  264K  /  1.7M 
current NORM/LOW  - 304k / 1.9M

LTO with the patch as given above - 300K
LTO and also BUILDLIBJDWP opt set to HIGH - 328K

So for gcc13.2 with lto enabled (300K) , the lib size gets slightly larger compared to gcc 11.3 with lto enabled (280K).

> It seems LTO would be good to enable regardless of the optimization level. 

Unfortunately I think we do not have many benchmarks for the JDK native libs, or maybe I am not aware of them ?

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

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

From nbenalla at openjdk.org  Thu Feb 20 16:02:18 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 20 Feb 2025 16:02:18 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools [v2]
In-Reply-To: <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
 <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>
Message-ID: <QhqUDXff_-BCM930uWA4igORBc595Wj5gt-VhxI-BaQ=.9025de7c-69a7-4c6b-baa6-902fc1d03137@github.com>

On Wed, 19 Feb 2025 16:05:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds
>> 
>> The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195
>> 
>> I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   respond to feedback

Thanks for reviewing Erik.

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

PR Comment: https://git.openjdk.org/jdk/pull/23697#issuecomment-2671911363

From nbenalla at openjdk.org  Thu Feb 20 16:02:19 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 20 Feb 2025 16:02:19 GMT
Subject: Integrated: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools
In-Reply-To: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
Message-ID: <VMMZ38jglHiELrlRlKAes5RfapxgZj1Rt1x8ZrVkiKM=.f4c024ec-5fe9-4550-a038-615b841d243d@github.com>

On Wed, 19 Feb 2025 14:34:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This patch fixes a regression where the windows tools man pages appeared on the Linux and the MacOS builds
> 
> The man pages found using `FindModuleManDirs` were used in both `Docs.gmk` used to generate the documentation for the JDK as well as in `LauncherCommon.gmk` here https://github.com/openjdk/jdk/blob/efbad00c4d7931177ccc5e9bce3b30dfbac94010/make/common/modules/LauncherCommon.gmk#L195
> 
> I've separated the logic between generated the docs and the man pages. I've checked on a MacOs machine and the man pages no longer appear.

This pull request has now been integrated.

Changeset: 53db5764
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53db57648a09c4c380064eea11fcdb680011d741
Stats:     9 lines in 2 files changed: 7 ins; 0 del; 2 mod

8350137: After JDK-8348975, Linux builds contain man pages for windows only tools

Reviewed-by: erikj

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

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

From shade at openjdk.org  Thu Feb 20 16:02:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Feb 2025 16:02:56 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
Message-ID: <K0geJgyI1RaS6Q8RsmvFTHZr07KTo3asPNXI7jplE3w=.8ec38219-6d01-4636-9524-ffb525ccf945@github.com>

On Thu, 6 Feb 2025 17:01:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?

> @shipilev Can you help review/approve the change, if no other questions?

Sorry for not looking at this sooner. 

It looks to me that you are trying to work-around a little mess introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). Not your mess, but trying to avoid it introduces more headaches. I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic `build-linux` job! It looks cleaner to yank `static-libs-bundles` into a separate build job, which would then allow your PR to proceed by just calling `build-linux` normally, without introducing a wholly new job script. Let me try to fix `static-libs-bundles` first.

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2671927912

From imyers at openjdk.org  Thu Feb 20 16:04:58 2025
From: imyers at openjdk.org (Ian Myers)
Date: Thu, 20 Feb 2025 16:04:58 GMT
Subject: RFR: 8350137: After JDK-8348975,
 Linux builds contain man pages for windows only tools [v2]
In-Reply-To: <QhqUDXff_-BCM930uWA4igORBc595Wj5gt-VhxI-BaQ=.9025de7c-69a7-4c6b-baa6-902fc1d03137@github.com>
References: <wDOtQSYvOeVCmJSBzyVwge6QKQwPYFZujoL0rM4g1FU=.a959e31a-03fd-4833-83ac-a4e83d873658@github.com>
 <qUGBKRP2_oWBfL0J6nyxyLmyNBwHYpvIdjmzrap3phY=.d67eb37f-89ef-44f3-8b9c-a080e5486891@github.com>
 <QhqUDXff_-BCM930uWA4igORBc595Wj5gt-VhxI-BaQ=.9025de7c-69a7-4c6b-baa6-902fc1d03137@github.com>
Message-ID: <HnDxOFrjcsRqqvJVknsdqGlGErXZj5MOl7VS28ohC64=.e6aec277-5b70-4e58-a087-c55bf6cd5bae@github.com>

On Thu, 20 Feb 2025 15:52:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   respond to feedback
>
> Thanks for reviewing Erik.

Thank you @nizarbenalla and @erikj79 for resolving this!

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

PR Comment: https://git.openjdk.org/jdk/pull/23697#issuecomment-2671940711

From ihse at openjdk.org  Thu Feb 20 16:41:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Feb 2025 16:41:52 GMT
Subject: RFR: 8349933: Mixing of includes and snippets stack causes the
 wrong -post snippet to be included
In-Reply-To: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
References: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
Message-ID: <aTz9quhCWOz3j5J4-Xwj9KwrCk2YSAC9ZJRWXS9BUhA=.05ec8934-3e12-4c73-b63a-5abe731b6502@github.com>

On Wed, 12 Feb 2025 20:37:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The new framework for tracing makefile inclusion has a bug. In the Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and THIS_SNIPPET respectively are restored from the HELPER_STACK variable. The problem is that we can't know if the next item on the stack is a previous "include" or "snippet". In a complex tree of includes/snippets, this can cause the wrong custom -post file to get included.
> 
> My proposed fix is to split HELPER_STACK into two variables, INCLUDE_STACK and SNIPPET_STACK, so we keep track of which files were includes and which ones were snippets. When printing indentations we just concatenate these variables to get the total stack size.
> 
> This patch fixes the observed issue for me locally. I'm running extensive testing on it.

LGTM. Thanks for fixing this! Somehow, sharing the HELPER_STACK irked me in the back of my mind, but I did not really listen enough to this warning signal to verify that it was indeed sane to do. (Which it turned out not to be...)

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23601#pullrequestreview-2630517792

From shade at openjdk.org  Thu Feb 20 17:20:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Feb 2025 17:20:08 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
Message-ID: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>

Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.

This effectively reverts parts of the original change, plus a few modifications:
 - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
 - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables

Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.

I did a partial GHA run already, and I expect full run to complete without errors.

Testing:
 - [ ] GHA

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

Commit messages:
 - Fix

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

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

From erikj at openjdk.org  Thu Feb 20 17:48:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Feb 2025 17:48:56 GMT
Subject: Integrated: 8349933: Mixing of includes and snippets stack causes the
 wrong -post snippet to be included
In-Reply-To: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
References: <xunGZIcEuYYlJrplVKq6dPMx2XqgXOhuhKB4duypivc=.fa1beef2-56ea-4948-ab7e-857a492bbb65@github.com>
Message-ID: <GxNrnQyGpPLNf58HKEg1CV1g2lo9mpLDhaM6Y0KbQf8=.6e8e46a6-aaee-45fe-bce6-f05954c02c0e@github.com>

On Wed, 12 Feb 2025 20:37:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The new framework for tracing makefile inclusion has a bug. In the Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and THIS_SNIPPET respectively are restored from the HELPER_STACK variable. The problem is that we can't know if the next item on the stack is a previous "include" or "snippet". In a complex tree of includes/snippets, this can cause the wrong custom -post file to get included.
> 
> My proposed fix is to split HELPER_STACK into two variables, INCLUDE_STACK and SNIPPET_STACK, so we keep track of which files were includes and which ones were snippets. When printing indentations we just concatenate these variables to get the total stack size.
> 
> This patch fixes the observed issue for me locally. I'm running extensive testing on it.

This pull request has now been integrated.

Changeset: 16873732
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16873732a752d79c3bf1bc450c63839997986d9e
Stats:     12 lines in 4 files changed: 0 ins; 0 del; 12 mod

8349933: Mixing of includes and snippets stack causes the wrong -post snippet to be included

Reviewed-by: ihse

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

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

From jiangli at openjdk.org  Thu Feb 20 18:19:53 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 18:19:53 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <K0geJgyI1RaS6Q8RsmvFTHZr07KTo3asPNXI7jplE3w=.8ec38219-6d01-4636-9524-ffb525ccf945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
 <K0geJgyI1RaS6Q8RsmvFTHZr07KTo3asPNXI7jplE3w=.8ec38219-6d01-4636-9524-ffb525ccf945@github.com>
Message-ID: <fFeb6bP6J1p2EvVWWOvzY92cmRwW6ujfDud0UXdV2vA=.863a8913-34f7-4e39-8ee4-9fc872a9af48@github.com>

On Thu, 20 Feb 2025 15:58:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > @shipilev Can you help review/approve the change, if no other questions?
> 
> Sorry for not looking at this sooner.
> 
> It looks to me that you are trying to work-around a little mess introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). Not your mess, but trying to avoid it introduces more headaches. I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic `build-linux` job! It looks cleaner to yank `static-libs-bundles` into a separate build job, which would then allow your PR to proceed by just calling `build-linux` normally, without introducing a wholly new job script. Let me try to fix `static-libs-bundles` first.

Thank you, @shipilev! Fixing the build-linux first sounds good to me. I see you have PR already, thanks again!

In fact, there is a similar build resource (disk space) issue for the static job as well. It requires some work in both the runtime and build system to address the underlying problem that causes excessive build resource consumption. I created https://bugs.openjdk.org/browse/JDK-8350450. @magicus has been looking into integrating (related runtime changes from hermetic-java-runtime branch) and fixing the issue in JDK mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2672313053

From dnsimon at openjdk.org  Thu Feb 20 19:52:52 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 20 Feb 2025 19:52:52 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <DyRBTz2g7WG4r_8d5duLfb6_gnp3E4B6Y6U670gJFSc=.117ff621-261c-4a01-9444-97df8c19e8ab@github.com>

On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

Please do not remove the static-lib-bundles - they are critical for testing OpenJDK PRs against libgraal: https://github.com/dougxc/openjdk-pr-canary/blob/9c38cdb2dcdbe4aef6b81732b3a296856ac1bb4c/.github/scripts/test-openjdk-pullrequests.py#L818
cc @mur47x111

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2672527713

From acobbs at openjdk.org  Thu Feb 20 21:05:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Feb 2025 21:05:22 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions that
 lose information
Message-ID: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.

I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!

Currently, we generate this warning, but only for assignment operators, e.g.:

int x = 0;
x += 1.0f;   // warning here


This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:

void method(float f) { }
...
float a = 0x10000001;   // warning here
method(0x10000001);     // warning here


It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:

float f1 = 0x10000000;     // no warning here

The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.

As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:


float a = (float)0x10000001;   // no warning here

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

Commit messages:
 - Warn for more widening primitive conversions that lose information.

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

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

From yzheng at openjdk.org  Thu Feb 20 21:11:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 20 Feb 2025 21:11:52 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <6fqE96gPDOJ3OLDBieU2Kw4Msoe9AqGvkgVtIG9anAM=.ab9ad094-428f-4b70-b5e4-d7798e6eee52@github.com>

On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

We are proactively ensuring Graal remains compatible with the OpenJDK master tip without requiring contributors to build libgraal. For example, we prepared [this Graal adaption patch](https://github.com/oracle/graal/pull/10562) to support your [DirectByteBuffers Cleaner work](https://github.com/openjdk/jdk/pull/22165). Removing static-lib-bundles would eliminate our canary tool's automation, significantly increasing manual effort. Please hold off on removing static-lib-bundles until we find a way into GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2672688231

From cjplummer at openjdk.org  Thu Feb 20 21:41:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Feb 2025 21:41:52 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: <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@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 just don't feel comfortable tinkering with the flags in this manner when we aren't sure of the potential performance impact. The footprint improvement is somewhat negligible in the big picture.

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

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

From acobbs at openjdk.org  Thu Feb 20 22:26:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Feb 2025 22:26:51 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions
 that lose information
In-Reply-To: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
Message-ID: <tUmGn7taMD0szY20hinxKuoMiSR0qUag5s1RRdrC1fQ=.f18ebda7-b25c-44e9-8965-1cece2db8787@github.com>

On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
> 
> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
> 
> Currently, we generate this warning, but only for assignment operators, e.g.:
> 
> int x = 0;
> x += 1.0f;   // warning here
> 
> 
> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
> 
> void method(float f) { }
> ...
> float a = 0x10000001;   // warning here
> method(0x10000001);     // warning here
> 
> 
> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
> 
> float f1 = 0x10000000;     // no warning here
> 
> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
> 
> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
> 
> 
> float a = (float)0x10000001;   // no warning here

Sorry for the mailing list spam - this PR discussion really only belongs on `compiler-dev`, but the bot added the others due to the changes to the corresponding makefile (which add `-Xlint:-lossy-conversions` to suppress the new warnings).

I'll remove `client`, `core-libs`, `hotspot-jfr` and `serviceability` but feel free to add them back if needed/desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2672826679

From jiangli at openjdk.org  Thu Feb 20 23:47:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 23:47:10 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK [v2]
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <7T4TxxbN8RmIWkFPp0UNjlXhs07kmaWTEiepZG77vtE=.02c46b3f-eb18-4a82-811a-a5ed1a87592f@github.com>

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

Jiangli Zhou 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:

 - Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java for static JDK.
 - Revert make/test/JtregNativeJdk.gmk and test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c changes.
 - Merge branch 'master' into JDK-8350041
 - Remove 'lib' prefix from 'java.dll'.
 - Update copyright header year.
 - - Change to call JNU_GetStringPlatformChars, JNU_ClassString and JNU_NewStringPlatform
     using the function addresses obtained from lookup. This allows building libstringPlatformChars
     without explicitly linking with libjava.so (or libjava.dll).
   - Remove #include "jni_util.h".
   - Add BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libstringPlatformChars := -ldl. It's needed to
     avoid build failure if the build is configured to not allow undefined symbols in shared
     library.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23646/files
  - new: https://git.openjdk.org/jdk/pull/23646/files/013b391b..1de95b89

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

  Stats: 7588 lines in 309 files changed: 3962 ins; 2555 del; 1071 mod
  Patch: https://git.openjdk.org/jdk/pull/23646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23646/head:pull/23646

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

From jiangli at openjdk.org  Thu Feb 20 23:47:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 23:47:10 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

> > I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.
> 
> Thanks, @AlanBateman. I think skipping this test for static JDK sounds reasonable to me, since this test seems to explicitly test these JNU_ functions. Changing to do dynamic lookup may alter the original intention. I'll update after #23528.

Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2672961034

From liach at openjdk.org  Fri Feb 21 00:06:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 00:06:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
Message-ID: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>

Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.

Reduces the instructions to execute this code in a simple main by 47%:

long[] arr = new long[8];
var ms = MemorySegment.ofArray(arr);
ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);


Main overheads in FFM are identified to be:
1. Eager initialization of direct MethodHandle; can be CDS archived
2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead

Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.

Tests: tier 1-3 running

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

Commit messages:
 - More cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Make sure the form impl class is initialized
 - Reduce MT initialization work
 - MH linkToStatic stall
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Enhance cache for basic value layouts
 - More stuff
 - VH inline stuff stage

Changes: https://git.openjdk.org/jdk/pull/23720/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350118
  Stats: 1869 lines in 16 files changed: 1056 ins; 215 del; 598 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

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

From alanb at openjdk.org  Fri Feb 21 06:59:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 06:59:52 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
Message-ID: <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>

On Thu, 20 Feb 2025 23:44:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.

Thanks. If you can bump the copyright header date then I think we are done with this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2673693612

From mbaesken at openjdk.org  Fri Feb 21 07:53:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Feb 2025 07:53:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@github.com>
Message-ID: <AoiE6dtloSKurgmG03hkkGDxY3ZcUFVDYDMxzJVkJ38=.84000b42-522a-4824-83fe-98c7e32371cc@github.com>

On Thu, 20 Feb 2025 21:39:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I just don't feel comfortable tinkering with the flags in this manner when we aren't sure of the potential performance impact. The footprint improvement is somewhat negligible in the big picture.

Without good benchmarks it is hard to say. But this is true also for the current 'LOW' opt setting that was available since jdk9 at least (probably much longer)
https://github.com/AdoptOpenJDK/openjdk-jdk9/blob/f00b63d24697cce8067f468fe6cd8510374a46f5/jdk/make/lib/Lib-jdk.jdwp.agent.gmk#L80
and in the meantime there were quite a few compiler updates.
Probably we could look at the performance of related jtreg tests so spot bad performance degradations.

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

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

From shade at openjdk.org  Fri Feb 21 08:29:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 08:29:28 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v2]
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <8Caxm-qsFpSu7L7bSKS-TtrL-Osh9DvrMT_nZ6Bvf5o=.82785254-a863-4c71-bc6e-fe54174d47f6@github.com>

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

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

  Upload static bundles again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23715/files
  - new: https://git.openjdk.org/jdk/pull/23715/files/584c26f3..95257a13

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

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

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

From shade at openjdk.org  Fri Feb 21 08:35:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 08:35:06 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v3]
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <uq-y8NlvtgtutktdhyCnyqMZoBSA3A-cJMoyyRb8dOM=.bbd0e84f-e1bb-4f0a-99f8-9a5c7620b806@github.com>

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

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

  Touch up comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23715/files
  - new: https://git.openjdk.org/jdk/pull/23715/files/95257a13..aadf9b6b

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

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

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

From shade at openjdk.org  Fri Feb 21 08:35:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 08:35:06 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v2]
In-Reply-To: <8Caxm-qsFpSu7L7bSKS-TtrL-Osh9DvrMT_nZ6Bvf5o=.82785254-a863-4c71-bc6e-fe54174d47f6@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <8Caxm-qsFpSu7L7bSKS-TtrL-Osh9DvrMT_nZ6Bvf5o=.82785254-a863-4c71-bc6e-fe54174d47f6@github.com>
Message-ID: <NA9eU_FHc-J1ok3ZHr6D_-yjz7iwjI-Tu-YzDouxzmg=.b14ac61f-4bfb-42dd-be48-7bdec9587750@github.com>

On Fri, 21 Feb 2025 08:29:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Upload static bundles again

OK, this downstream use should really be documented if you want people to know why it should persist. New version does a comment hopefully explaining this. The static bundle is uploaded, but now separately, in `linux-x64-static`. I am guessing that would work for Graal downstream?

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2673901613

From mbaesken at openjdk.org  Fri Feb 21 08:35:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Feb 2025 08:35:53 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: <u_10Zet8fQY_JZZdCJ7W8LqAC-VyslvL5K692lNb_g4=.8af82114-dcfa-41e1-a93c-4dcba4022ff1@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 .

Btw. regarding footprint improvement, for some vendors it seems to be important, see 'Liberica JDK Lite' 
https://docs.bell-sw.com/liberica-jdk/latest/how-to/choosing-flavor/
(however I couldn't figure out from the page if they apply LTO on all native libs or only libjvm)

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

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

From shade at openjdk.org  Fri Feb 21 08:42:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 08:42:55 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <K0geJgyI1RaS6Q8RsmvFTHZr07KTo3asPNXI7jplE3w=.8ec38219-6d01-4636-9524-ffb525ccf945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <svYWdmGuXN7S7j_5K1ABoRFPoRotyzD-vB-kK7RcZGQ=.1bd1ea36-9137-4daa-b24e-08d97bf91401@github.com>
 <K0geJgyI1RaS6Q8RsmvFTHZr07KTo3asPNXI7jplE3w=.8ec38219-6d01-4636-9524-ffb525ccf945@github.com>
Message-ID: <d2mB8vc0qm5c8iT9nB598Idv0N-SH6m_PVs0MyGpfcQ=.deb46b90-9633-4399-9864-ec37a3b25242@github.com>

On Thu, 20 Feb 2025 15:58:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> What's the difference between `build-linux-static.yml` and `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?
>
>> @shipilev Can you help review/approve the change, if no other questions?
> 
> Sorry for not looking at this sooner. 
> 
> It looks to me that you are trying to work-around a little mess introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). Not your mess, but trying to avoid it introduces more headaches. I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic `build-linux` job! It looks cleaner to yank `static-libs-bundles` into a separate build job, which would then allow your PR to proceed by just calling `build-linux` normally, without introducing a wholly new job script. Let me try to fix `static-libs-bundles` first.

> Thank you, @shipilev! Fixing the build-linux first sounds good to me. I see you have PR already, thanks again!

Hey @jianglizhou, a quick question for you. There are two options for this PR:
  1. Build both `static-jdk-image` and `static-libs-bundle` in the same `linux-x64-static` job from #23715 
  2. Build `static-jdk-image` and `static-libs-bundle` in different jobs

Which one would you prefer? I would prefer to test all static stuff in a single job (1), unless you disagree? If we decide now, it would allow me to name the job in #23715 properly from the start.

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2673918096

From abimpoudis at openjdk.org  Fri Feb 21 09:59:55 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 21 Feb 2025 09:59:55 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions
 that lose information
In-Reply-To: <tUmGn7taMD0szY20hinxKuoMiSR0qUag5s1RRdrC1fQ=.f18ebda7-b25c-44e9-8965-1cece2db8787@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
 <tUmGn7taMD0szY20hinxKuoMiSR0qUag5s1RRdrC1fQ=.f18ebda7-b25c-44e9-8965-1cece2db8787@github.com>
Message-ID: <uPsmtddAD1hh-xXOaDjdJ1TJIHgSYVdCbCPMWZHgoPE=.d2a46075-e65d-470d-ba8d-09c0807ae5ee@github.com>

On Thu, 20 Feb 2025 22:24:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
>> 
>> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
>> 
>> Currently, we generate this warning, but only for assignment operators, e.g.:
>> 
>> int x = 0;
>> x += 1.0f;   // warning here
>> 
>> 
>> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
>> 
>> void method(float f) { }
>> ...
>> float a = 0x10000001;   // warning here
>> method(0x10000001);     // warning here
>> 
>> 
>> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
>> 
>> float f1 = 0x10000000;     // no warning here
>> 
>> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
>> 
>> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
>> 
>> 
>> float a = (float)0x10000001;   // no warning here
>
> Sorry for the mailing list spam - this PR discussion really only belongs on `compiler-dev`, but the bot added the others due to the changes to the corresponding makefile (which add `-Xlint:-lossy-conversions` to suppress the new warnings).
> 
> I'll remove `client`, `core-libs`, `hotspot-jfr` and `serviceability` but feel free to add them back if needed/desired.

@archiecobbs this is excellent work! Thank you for the initiative and the patch which was on the right direction to address this issue.

There are several reasons that it would be ideal to hold this PR off, for now. There is an ongoing effort to study conversions and contexts holistically in Java and possibly regularizing various contexts across the board.

That study will build upon the implementation (and terminology) realised by JEP 488 regarding exact and lossy conversions which might well include the warnings contained in your PR. 

I am re-assigning this to me on JBS and I will link back to it when the new JBS ticket is created.

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

PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2674096146

From mcimadamore at openjdk.org  Fri Feb 21 10:03:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:03:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 45:

> 43:   $1_Type := $2
> 44: 
> 45:   ifeq ($$($1_Type), Boolean)

These changes in ScopedMemoryAccess are not strictly required -- but I imagine they simplify your implementation of the var handle impl methods. So, it's ok to leave them in.

make/modules/java.base/gensrc/GensrcVarHandles.gmk line 171:

> 169: # Param 1 - Variable declaration prefix
> 170: # Param 2 - Type with first letter capitalized
> 171: # TODO decide if CAS/Bitwise/AtomicAdd should be enabled for subints

Exactly - let's keep this out for now (they seem to be currently enabled -- and I'd prefer to do that separately, after some discussion)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965204113
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965202095

From mcimadamore at openjdk.org  Fri Feb 21 10:07:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:07:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:

> 1554: 
> 1555:             @Override
> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {

When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).

src/java.base/share/classes/java/lang/invoke/VarForm.java line 70:

> 68:     VarForm(Class<?> implClass, VarForm methodTypeSource) {
> 69:         this.implClass = implClass;
> 70:         // methodTypeSource already called initMethodTypes

can we turn this comment into an assertion?

src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:

> 148:         String methodName = value.methodName();
> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;

Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965208913
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965210069
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965211558

From mcimadamore at openjdk.org  Fri Feb 21 10:18:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:18:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/java/lang/invoke/VarHandleSegmentViewBase.java line 34:

> 32:  * Base class for memory segment var handle view implementations.
> 33:  */
> 34: final class VarHandleSegmentViewBase extends VarHandle {

Should the name of this class change so that we drop `Base` ? It's no longer extended by anything.

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 767:

> 765: //                    new HandleType(Object.class, long.class),
> 766: //
> 767: //                    // MS[base][offset]->T

I like how you programmatically generate all guards for all the shapes we care about.

On `MS[base][offset]` I wonder if generating a guard matters (for now) given that such a var handle will be indirect?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:

> 75:         }
> 76: 
> 77:         @ForceInline

Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 85:

> 83: 
> 84:         @ForceInline
> 85:         static $type$ get(VarHandle ob, Object obb, long base) {

I like this: a fast path for non-strided access, while, at the same time, reusing the impl.
In the future we can also add another variant for when there's only one index (which is by far the most common case).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965223737
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965218844
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965222924
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965226302

From mcimadamore at openjdk.org  Fri Feb 21 10:27:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:27:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <xLnepF4ybHY2H0J72WNtKFIjg_eBYAKYO-SttMpLgEI=.be7d1a89-227f-496e-9eff-0fdf2a177f1b@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 210:

> 208: 
> 209:         // (MS, long, long) if has strides, (MS, long) if no stride
> 210:         VarHandle handle = Utils.makeRawSegmentViewVarHandle(rootLayout(), valueLayout, strides.length == 0, offset);

Super! To make the code clearer - I would assign `strides.length == 0` to a local variable, and then reuse that variable both here and in the branch below (to make it more explicit that the two things are connected -- e.g. no stride, no need for adaptation)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965239357

From mcimadamore at openjdk.org  Fri Feb 21 10:30:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:30:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <etkFO6pJadhT4JbyJnZZSUaG6YqqQLmxOo38FFHzyws=.26406444-4738-4fdd-b4a4-63f960cc5def@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:

> 75: 
> 76:     private static MethodHandle computeFilterHandle(int index) {
> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();

please break this big conditional up!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965244316

From dnsimon at openjdk.org  Fri Feb 21 10:51:52 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 21 Feb 2025 10:51:52 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v2]
In-Reply-To: <NA9eU_FHc-J1ok3ZHr6D_-yjz7iwjI-Tu-YzDouxzmg=.b14ac61f-4bfb-42dd-be48-7bdec9587750@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <8Caxm-qsFpSu7L7bSKS-TtrL-Osh9DvrMT_nZ6Bvf5o=.82785254-a863-4c71-bc6e-fe54174d47f6@github.com>
 <NA9eU_FHc-J1ok3ZHr6D_-yjz7iwjI-Tu-YzDouxzmg=.b14ac61f-4bfb-42dd-be48-7bdec9587750@github.com>
Message-ID: <7qO2rZALnY7G7pwXfviZcTQbeT26UNiC20Nv4gmc9NA=.96036200-6e88-4320-a0eb-686bc273f9e3@github.com>

On Fri, 21 Feb 2025 08:32:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OK, this downstream use should really be documented if you want people to know why it should persist. New version does a comment hopefully explaining this. The static bundle is uploaded, but now separately, in `linux-x64-static`. I am guessing that would work for Graal downstream?

Thanks for adding the comment!
We are now [adapting the canary](https://github.com/dougxc/openjdk-pr-canary/pull/1) to work with both the old and new location of static-libs bundles.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2674217760

From mcimadamore at openjdk.org  Fri Feb 21 11:04:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:04:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <iQEdcnbJgEIJParqw13U1TRp_mPWkUpAOkn8mGOLM5w=.552276ad-c626-47c4-a649-783c12d47745@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:

> 162:         @ForceInline
> 163:         public final VarHandle varHandle() {
> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {

Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965294264

From mcimadamore at openjdk.org  Fri Feb 21 11:08:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:08:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Overall, this is a great cleanup and consolidation of the memory segment VH code. I left various comments -- but this is already in a great shape. Thanks!

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

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2632727514

From mcimadamore at openjdk.org  Fri Feb 21 11:08:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:08:56 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>
Message-ID: <xHrSIGoarEAIgYesTWOdf2MY2IwphxKHk3jDFzZNUo4=.462ec623-5a77-44ca-bb1b-5e241be12e43@github.com>

On Fri, 21 Feb 2025 11:05:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Overall, this is a great cleanup and consolidation of the memory segment VH code. I left various comments -- but this is already in a great shape. Thanks!

It would be useful to run some micro benchmarks before/after -- especially those starting with "LoopOver*" and see if anything jumps out.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2674259763

From mcimadamore at openjdk.org  Fri Feb 21 11:12:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:12:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <Hcss2BTOqMfZp2_jSnbGCKTxoXvmE5tNtUAbhgSEhnA=.a9c324b2-6bea-4f7d-a390-66c0f3df722b@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

I wonder if the changes affecting `isAccessModeSupported` should warrant a small CSR?

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2674266390

From rgiulietti at openjdk.org  Fri Feb 21 11:33:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 21 Feb 2025 11:33:52 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions
 that lose information
In-Reply-To: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
Message-ID: <pTKlzdhc8F8-8N6QCG5AMW19quyIWTnqqv0_BgseZmI=.7acc97a5-ddb5-48d4-8f81-113671b888c6@github.com>

On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
> 
> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
> 
> Currently, we generate this warning, but only for assignment operators, e.g.:
> 
> int x = 0;
> x += 1.0f;   // warning here
> 
> 
> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
> 
> void method(float f) { }
> ...
> float a = 0x10000001;   // warning here
> method(0x10000001);     // warning here
> 
> 
> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
> 
> float f1 = 0x10000000;     // no warning here
> 
> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
> 
> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
> 
> 
> float a = (float)0x10000001;   // no warning here

The "roundtrip technique" is not always sufficient.
For example, `(int) (float) Integer.MAX_VALUE == Integer.MAX_VALUE` evaluates to `true`, despite `Integer.MAX_VALUE)` not being exactly representable by `float`.

You may want to take a look at `java.lang.runtime.ExactConversionsSupport`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2674307463

From liach at openjdk.org  Fri Feb 21 13:56:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 13:56:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
Message-ID: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>

On Fri, 21 Feb 2025 09:59:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> make/modules/java.base/gensrc/GensrcVarHandles.gmk line 171:
> 
>> 169: # Param 1 - Variable declaration prefix
>> 170: # Param 2 - Type with first letter capitalized
>> 171: # TODO decide if CAS/Bitwise/AtomicAdd should be enabled for subints
> 
> Exactly - let's keep this out for now (they seem to be currently enabled -- and I'd prefer to do that separately, after some discussion)

I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:
> 
>> 1554: 
>> 1555:             @Override
>> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {
> 
> When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).

Shouldn't this be called noStride then?

> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 767:
> 
>> 765: //                    new HandleType(Object.class, long.class),
>> 766: //
>> 767: //                    // MS[base][offset]->T
> 
> I like how you programmatically generate all guards for all the shapes we care about.
> 
> On `MS[base][offset]` I wonder if generating a guard matters (for now) given that such a var handle will be indirect?

Yes, it avoids the extra generation of vh linker lambda forms.

> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:
> 
>> 75: 
>> 76:     private static MethodHandle computeFilterHandle(int index) {
>> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();
> 
> please break this big conditional up!

This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965506674
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965508406
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965504398
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965512480

From erikj at openjdk.org  Fri Feb 21 14:07:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Feb 2025 14:07:03 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v3]
In-Reply-To: <uq-y8NlvtgtutktdhyCnyqMZoBSA3A-cJMoyyRb8dOM=.bbd0e84f-e1bb-4f0a-99f8-9a5c7620b806@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <uq-y8NlvtgtutktdhyCnyqMZoBSA3A-cJMoyyRb8dOM=.bbd0e84f-e1bb-4f0a-99f8-9a5c7620b806@github.com>
Message-ID: <dUUmDvOQlrlikKvs8v9q4TyXuMK148uOw5XrVkhUH3I=.784ab039-d1e8-4582-b394-aff20bd19033@github.com>

On Fri, 21 Feb 2025 08:35:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touch up comment

I'm not sure splitting static out into it's own task is the right long term direction we should be heading in. Magnus is working on reducing the duplicated work needed to build both a regular JDK and static libs at the same time, by reusing all the object files. 

I would also argue that there is a big difference between the old static-libs-bundle and the new static JDK distribution conceptually, so bunching them up in the same "static" category doesn't make much sense to me, other than as a (misguided) attempt at optimizing GHA compute resources. The old static-libs-bundle is static versions of JDK libs needed by certain downstream consumers of the regular JDK distribution (Graal). This is essentially an extension of the regular JDK. The new static JDK distro that @jianglizhou and @magicus are working on is a complete separate JDK variant that replaces the regular JDK.

Having one build task produce more than one JDK for testing can cause a challenge in the model for a build and test system, so for that reason it makes sense having a separate build task for the static JDK. That would also isolate build problems with the static JDK and avoid having them block test results for the regular JDK. I never delved deep enough into GHA to know if this would cause an issue here or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2674635422

From shade at openjdk.org  Fri Feb 21 14:24:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 14:24:22 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

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

  Rename -static job to -static-libs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23715/files
  - new: https://git.openjdk.org/jdk/pull/23715/files/aadf9b6b..356f1fa8

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

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

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

From shade at openjdk.org  Fri Feb 21 14:34:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Feb 2025 14:34:56 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
Message-ID: <cFNyh1m-RS0VWr47Rwb3_jJc06v9ggIdO0VncWO97EU=.74678cde-d835-469c-ad48-5b9331a57f50@github.com>

On Fri, 21 Feb 2025 14:24:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename -static job to -static-libs

The point about difference between `static-libs` and `static` JDK is valid. I renamed the job to `-static-libs`, and would expect #23471 to add another job like `build-linux-x64-static` that would build static JDK.

Conceptually, I have major reservations about sneaking in `static-libs-bundle` make target in the generic `build-linux` job script. It might have been OK when it was originally done, but it is IMO a hacky solution, which prompts even more hacks to workaround the first hack! See #23471. We are also "lucky" that no other jobs call into `build-linux` script with `release`, so we are not building `static-libs-bundle` in all cross-compilation, no-pch, Zero and other jobs that only ask for `hotspot`, for example. 

If we want to build `static-libs-bundle` only for Linux x64 release, the clean way to do this is to explicitly define it as separate job.

At some point in the future -- once build system catches up -- we _may_ consider adding `static-libs-bundles` into default make target list in `build-linux` / `build-windows` / etc. scripts. This would also be clean. But before that happens, the non-standard build targets have IMO no business being spliced into the generic scripts.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2674707774

From mcimadamore at openjdk.org  Fri Feb 21 14:46:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 14:46:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
Message-ID: <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>

On Fri, 21 Feb 2025 13:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.

Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:
>> 
>>> 1554: 
>>> 1555:             @Override
>>> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {
>> 
>> When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).
>
> Shouldn't this be called noStride then?

noStride works (I was mostly suggesting that appealing to the concept of "there's a stride or not" might be more useful)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965596079
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965598874

From mcimadamore at openjdk.org  Fri Feb 21 14:53:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 14:53:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
Message-ID: <_HjEh41bJQXpl2my0adypBMQou6-51j9TGg9nXEHBvc=.248ba429-a846-4045-af59-fc186026dd42@github.com>

On Fri, 21 Feb 2025 13:53:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:
>> 
>>> 75: 
>>> 76:     private static MethodHandle computeFilterHandle(int index) {
>>> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 
>> please break this big conditional up!
>
> This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?

I mean - using a single expression which is a conditional with two big switches seems quite unreadable.I suggest to move the `VH_FILTERS[index] = ` assignment out of the `computeFilterHandle` method. Then, rewrite `computeFilterHandle` as:


if (addressSize != 4) {
    return switch ...
} else {
    return switch ...
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965609458

From liach at openjdk.org  Fri Feb 21 16:08:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 16:08:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
Message-ID: <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>

On Fri, 21 Feb 2025 10:12:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:
> 
>> 75:         }
>> 76: 
>> 77:         @ForceInline
> 
> Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?

Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?

> src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:
> 
>> 162:         @ForceInline
>> 163:         public final VarHandle varHandle() {
>> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {
> 
> Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?

We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965763775
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965771047

From acobbs at openjdk.org  Fri Feb 21 16:51:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 21 Feb 2025 16:51:38 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions
 that lose information [v2]
In-Reply-To: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
Message-ID: <ae54fiCPhxbrAWxIz-zp5ZcbucJyMl3STq4sJ3yDsjA=.b4acc5f6-0339-4fe1-b043-e28260f1df19@github.com>

> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
> 
> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
> 
> Currently, we generate this warning, but only for assignment operators, e.g.:
> 
> int x = 0;
> x += 1.0f;   // warning here
> 
> 
> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
> 
> void method(float f) { }
> ...
> float a = 0x10000001;   // warning here
> method(0x10000001);     // warning here
> 
> 
> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
> 
> float f1 = 0x10000000;     // no warning here
> 
> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
> 
> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
> 
> 
> float a = (float)0x10000001;   // no warning here

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

  Check exactness of conversions using ExactConversionsSupport.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23718/files
  - new: https://git.openjdk.org/jdk/pull/23718/files/48680ecb..92b479a9

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

  Stats: 98 lines in 5 files changed: 64 ins; 2 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/23718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718

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

From acobbs at openjdk.org  Fri Feb 21 16:51:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 21 Feb 2025 16:51:38 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions
 that lose information
In-Reply-To: <pTKlzdhc8F8-8N6QCG5AMW19quyIWTnqqv0_BgseZmI=.7acc97a5-ddb5-48d4-8f81-113671b888c6@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
 <pTKlzdhc8F8-8N6QCG5AMW19quyIWTnqqv0_BgseZmI=.7acc97a5-ddb5-48d4-8f81-113671b888c6@github.com>
Message-ID: <1bEXTqphBLHTtvUwT4nmNwTttIyspwpfOLwF1m9wxOc=.d8d78754-fdf5-4e6d-8a38-0dbdbc7e8439@github.com>

On Fri, 21 Feb 2025 11:31:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> You may want to take a look at `java.lang.runtime.ExactConversionsSupport`.

Thanks! That's exactly what I needed. Fixed in 92b479a94ff.

> There are several reasons that it would be ideal to hold this PR off, for now. There is an ongoing effort to study conversions and contexts holistically in Java and possibly regularizing various contexts across the board.
> 
> That study will build upon the implementation (and terminology) realised by JEP 488 regarding exact and lossy conversions which might well include the warnings contained in your PR.
> 
> I am re-assigning this to me on JBS and I will link back to it when the new JBS ticket is created.

OK sounds good - it's all yours :) I will close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2675056823

From acobbs at openjdk.org  Fri Feb 21 16:51:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 21 Feb 2025 16:51:38 GMT
Subject: Withdrawn: 8261669: Add lint warning for widening primitive
 conversions that lose information
In-Reply-To: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
References: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>
Message-ID: <gl7D0_AC2V9ixqS93lE6NkNip3srp2Wi2HTySI7fPL0=.e3a4c90d-b720-4a8a-b7c9-c4520bd21aa9@github.com>

On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
> 
> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
> 
> Currently, we generate this warning, but only for assignment operators, e.g.:
> 
> int x = 0;
> x += 1.0f;   // warning here
> 
> 
> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
> 
> void method(float f) { }
> ...
> float a = 0x10000001;   // warning here
> method(0x10000001);     // warning here
> 
> 
> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
> 
> float f1 = 0x10000000;     // no warning here
> 
> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
> 
> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
> 
> 
> float a = (float)0x10000001;   // no warning here

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.org  Fri Feb 21 18:40:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 18:40:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
Message-ID: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>

On Fri, 21 Feb 2025 16:04:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:
>> 
>>> 75:         }
>>> 76: 
>>> 77:         @ForceInline
>> 
>> Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?
>
> Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?

Maybe let's leave it, at least in this round

>> src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:
>> 
>>> 162:         @ForceInline
>>> 163:         public final VarHandle varHandle() {
>>> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {
>> 
>> Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?
>
> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?

I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966002718
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965999335

From liach at openjdk.org  Fri Feb 21 18:56:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 18:56:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
Message-ID: <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>

On Fri, 21 Feb 2025 18:34:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?
>
> I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one

Indeed, the other cache already handles this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966022359

From jiangli at openjdk.org  Fri Feb 21 19:04:31 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Feb 2025 19:04:31 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK [v3]
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23646/files
  - new: https://git.openjdk.org/jdk/pull/23646/files/1de95b89..1a51b701

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

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

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

From jiangli at openjdk.org  Fri Feb 21 19:07:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Feb 2025 19:07:56 GMT
Subject: RFR: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK
In-Reply-To: <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
 <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>
Message-ID: <0jmPQX54MjO0zkvR3rL6Wu-UgJM5y9k5jp65oMBYlbs=.b9fb1c5d-4bc8-4f1d-a2ee-ce3d7027ad1a@github.com>

On Fri, 21 Feb 2025 06:57:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.
> 
> Thanks. If you can bump the copyright header date then I think we are done with this one.

Done, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2675329710

From cjplummer at openjdk.org  Fri Feb 21 19:09:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Feb 2025 19:09:54 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: <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@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 .

When minimalVM support was added, before the current configure based build system, choosing minmalVM did two things: it omitted some hotspot features from the JVM (like JVMTI, and libjdwp.so as a consequence) and it compiled many files with Os instead of O2 or O3. I think it still works like that with the current build system, but I'm not certain. A lot of benchmarking was done to avoid using Os for files that were important for overall performance, but some performance impact was allowed. After all, choosing minimalVM was in part a size vs performance choice, so having some performance hit in order to reduce the size was acceptable. We just tried to minimize the performance lost by being smart about which files were compiled with -Os.

My point here is that if you want small footprint, you can choose that, and expect some performance hit as a result, but this footprint/performance choice should be just that, a choice (like choosing minimalVM). You are suggesting potentially sacrificing some performance for reduced footprint (and a tiny footprint reduction at that) without it being a choice.

Yes, Liberica does care about footprint, but they are making sacrifices to reduce the footprint because they have small footprint goals that in part outweigh some performance or functionality goals. This is akin to the minimalVM approach. If anything, useful build system support for Liberica would come in the way of making it configurable whether libjdwp.so (and other libs) are built for size or built for performance.

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

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

From liach at openjdk.org  Fri Feb 21 20:14:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 20:14:19 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

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

  Review remarks, dates, some more simplifications

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/02c6faa1..c4af6ebf

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

  Stats: 427 lines in 13 files changed: 136 ins; 113 del; 178 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

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

From liach at openjdk.org  Fri Feb 21 20:19:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 20:19:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
Message-ID: <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>

On Fri, 21 Feb 2025 14:43:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
>
>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
> 
> Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)

Left a space and an extra note to make the comment hash more obvious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966119784

From jiangli at openjdk.org  Fri Feb 21 21:55:54 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Feb 2025 21:55:54 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
Message-ID: <oPcAJyzziw6giVs8TJMUDlNgGcgyEVPV6yFKYHQqakk=.6b8a2778-8058-401d-8e6a-833ae7493122@github.com>

On Fri, 21 Feb 2025 14:24:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename -static job to -static-libs

Yes, we should distinguish between `static-libs` and `static` JDK. Currently, we refer `static` JDK as a 'fully' statically linked `java` launcher, plus `lib/modules` and other JDK resource files needed for runtime. 

For longer term, including `static-libs-bundles` by default may be what we want. For example, in our current hermetic Java prototype, we release a regular JDK + static-libs. The final hermetic Java image creation step builds the single image using:

- launcher (code)
- JDK/hostpot `static-libs`
- lib/modules
- JDK resource files
- application classes and resources
- application natives and dependencies

During the image creation process, a launcher executable is linked using the launcher `.o` file, (needed) JDK/hotspot static libs, application natives and dependencies (in `.o` files or static libraries).

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2675623362

From mcimadamore at openjdk.org  Fri Feb 21 22:15:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 22:15:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:

> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.

I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966264372

From liach at openjdk.org  Fri Feb 21 22:15:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 22:15:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
Message-ID: <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>

On Fri, 21 Feb 2025 22:11:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:
> 
>> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
>> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
>> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.
> 
> I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)

The first level is right, it is the instance field AbstractValueLayout.handle. The static final CHM over there was not mentioned and is now removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966265626

From liach at openjdk.org  Fri Feb 21 22:21:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 22:21:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.

Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
LoopOverNonConstantHeap.unsafe_loop                                 false  avgt   30  0.205 ? 0.004  ms/op
LoopOverNonConstantHeap.unsafe_loop                                  true  avgt   30  0.204 ? 0.004  ms/op

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2675734830

From alanb at openjdk.org  Sat Feb 22 07:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Feb 2025 07:35:52 GMT
Subject: RFR: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK [v3]
In-Reply-To: <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>
Message-ID: <FPczF-3BT_PgnN8d-d7hR-OgeI8NGS9OzBzAYIm5FqU=.d05c9ef2-bb35-403d-8eff-06ae0b47dbd1@github.com>

On Fri, 21 Feb 2025 19:04:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
>> 
>> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
>> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
>> - Link with `-ldl` explicitly
>> 
>> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23646#pullrequestreview-2634741045

From jiangli at openjdk.org  Sun Feb 23 02:38:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sun, 23 Feb 2025 02:38:57 GMT
Subject: Integrated: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <ONy-QY43H0jq-ZlRjZu3dzpXNWilDW0ecRbvvX0TK44=.1bd18613-1b61-456a-86f9-cef4195b6e8e@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

This pull request has now been integrated.

Changeset: 05b48129
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05b481294cbf2ad7c8d917b8e039e7aebcf91104
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK

Reviewed-by: alanb

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

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

From mbaesken at openjdk.org  Mon Feb 24 08:15:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 08:15:55 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: <zO5fnlrk_INx_PHArYZNxoj1u6u9AfYwlShYl0b8TeE=.ffa81119-043d-43b6-a243-aceff9686c80@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 .

Hi Chris, thanks for the explanation and details of the minimal-vm .

> My point here is that if you want small footprint, you can choose that, and expect some performance hit as a result

Unfortunately , the JDK native libs are always compiled with the default settings (mostly LOW, for a few HIGH(EST))  so I cannot choose much. The minimal vm is interesting but as it is, it is not really a good choice.
Maybe we need better configure support to influence how the JDK libs are built.

On the other hand , most JDK libs have optimization LOW set, that does not look like they care too much about best performance.

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

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

From mcimadamore at openjdk.org  Mon Feb 24 11:31:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Feb 2025 11:31:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
 <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>
Message-ID: <gN0tmKgAlcrnaMkrz1o8q0m9T609CRIP3VqxDSpjvJk=.b1660524-0ccb-4e7f-8f11-38f2276abc04@github.com>

On Fri, 21 Feb 2025 22:12:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:
>> 
>>> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
>>> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
>>> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.
>> 
>> I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)
>
> The first level is right, it is the instance field AbstractValueLayout.handle. The static final CHM over there was not mentioned and is now removed

I've re-read this, and I see how `cached inside a stable field` doesn't really imply use of map or something else. So yes, this text is still ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1967464555

From mcimadamore at openjdk.org  Mon Feb 24 11:36:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Feb 2025 11:36:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 130:

> 128:      */
> 129:     public static VarHandle makeRawSegmentViewVarHandle(MemoryLayout enclosing, ValueLayout layout, boolean noStride, long offset) {
> 130:         if (enclosing instanceof ValueLayout direct) {

For now the caching is ok. Moving forrward, I wonder if we shouldn't add more reuse between field var handles in cases like these:


struct Point {
   int x; int y;
}



struct Tuple {
   int u; int v;
}


E.g. if I access the first field in these two structs, then the var handle will be identical? In a way, we use the enclosing layout for two reasons:

* to determine the size `S` of the accessed memory region
* to determine the alignment `A` of the accessed memory region

So, if the static `offset`, accessed `layout`, `S` and `A` are the same for two accesses, we should probably reuse the same var handle instance? E.g. whether we access `x` in a `Point`, or `u` in a `Tuple` makes little difference.

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

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2636794415
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1967472774

From mbaesken at openjdk.org  Mon Feb 24 11:40:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 11:40:54 GMT
Subject: RFR: 8346987: [lto] gtest build fails
In-Reply-To: <-MJ1mHsvXEaIqq6IIvQQ-iDjj6g6HaTaqQrggG-Ztcw=.c11edb36-647d-4b89-a3aa-eb503d748c2f@github.com>
References: <uXqt6XqvXe6N1jdUm4xR3MoIjibkBUip9mKKn4LnRwc=.7edf5a95-aaf9-4536-bc85-5ebfde400465@github.com>
 <eTMS2jd_58MNXLZd-eqXCx_mU0fsqXg9N2CBjdA3YG0=.52232017-dd31-4cc2-9f51-2a98fff9ddf1@github.com>
 <-MJ1mHsvXEaIqq6IIvQQ-iDjj6g6HaTaqQrggG-Ztcw=.c11edb36-647d-4b89-a3aa-eb503d748c2f@github.com>
Message-ID: <uQWyC1-AoOPCSP7rn3XbhrutkLIATujQPdunPHA-V34=.206739a5-ad3e-413b-a252-b3073bf99f58@github.com>

On Mon, 27 Jan 2025 07:59:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I'll try to prioritize separating gtest and hotspot builds, and then it will be possible to fix this in a clean way.

Hi @magicus was there some progress on this topic ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23173#issuecomment-2678162921

From mbaesken at openjdk.org  Mon Feb 24 12:42:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 12:42:53 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: <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@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 .

To be sure, I did a minimal build on Linux x86_64.  I set `--with-jvm-features=minimal --with-jvm-variants=minimal`  for this.
This leads to 
`JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`
So no jvmti, to GCs except serialgc . Just C1, no C2.  The 'opt-size' flag is set so the libjvm is compiled with size optimization (on Linux -Os).  The other native libs (JDK native libs) still use the opt-flags they always use, as I thought.

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

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

From mbaesken at openjdk.org  Mon Feb 24 13:59:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 13:59:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@github.com>
Message-ID: <J35iTpnRtZgWhlPCQ0PWQjGGqoC0eicvO6JBSu6ny4g=.9c95dd07-30bd-41b9-b8ae-ba66034d84ae@github.com>

On Fri, 21 Feb 2025 19:07:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> You are suggesting potentially sacrificing some performance for reduced footprint (and a tiny footprint reduction at that) without it being a choice

On some platforms we might have a (small)  performance impact when going from LOW/NORM to SIZE  (e.g. with MSVC it is the same settings anyways). But without benchmarks it is hard to say if there really is a decline in performance (and if so, how much).
My assumption (after talking to our leading debugging expert) was that libjdwp is not very performance critical but maybe this was wrong.
On the other hand we can achieve good performance _and_ smaller binaries with lto (at least with gcc).

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

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

From stuefe at openjdk.org  Mon Feb 24 14:16:14 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 24 Feb 2025 14:16:14 GMT
Subject: RFR: 8346987: [lto] gtest build fails
In-Reply-To: <eTMS2jd_58MNXLZd-eqXCx_mU0fsqXg9N2CBjdA3YG0=.52232017-dd31-4cc2-9f51-2a98fff9ddf1@github.com>
References: <uXqt6XqvXe6N1jdUm4xR3MoIjibkBUip9mKKn4LnRwc=.7edf5a95-aaf9-4536-bc85-5ebfde400465@github.com>
 <eTMS2jd_58MNXLZd-eqXCx_mU0fsqXg9N2CBjdA3YG0=.52232017-dd31-4cc2-9f51-2a98fff9ddf1@github.com>
Message-ID: <yEgbtpTdc3MC84iUEmHeLQBabMZXrh72mJiBiMdArV4=.f8715ca4-ba8e-4374-8d6f-689d87959663@github.com>

On Fri, 24 Jan 2025 17:22:46 GMT, Magnus Ihse Bursie <ihse 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 .
>
> Maybe we should heed @kimbarrett's advice and not push for the LTO stuff piecemeal like this. Personally, I rather think the best solution for now is to wait with this patch, and for you to continue configuring without gtest, than uglifying the code like this. I'll try to prioritize separating gtest and hotspot builds, and then it will be possible to fix this in a clean way.

@magicus about https://bugs.openjdk.org/browse/JDK-8296497, its a bit sparse on the details. What exactly is your plan, to build the gtest object files separately, but leave the linking stage as it is? Or build the gtest parts as an own launcher and link against the libjvm.so? The latter, I think, could be quite difficult since we expect to have access to all symbols in the gtest suite.

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

PR Comment: https://git.openjdk.org/jdk/pull/23173#issuecomment-2678536432

From liach at openjdk.org  Mon Feb 24 17:57:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
Message-ID: <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>

On Fri, 21 Feb 2025 18:37:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?
>
> Maybe let's leave it, at least in this round

Done in latest update.

>> This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?
>
> I mean - using a single expression which is a conditional with two big switches seems quite unreadable.I suggest to move the `VH_FILTERS[index] = ` assignment out of the `computeFilterHandle` method. Then, rewrite `computeFilterHandle` as:
> 
> 
> if (addressSize != 4) {
>     return switch ...
> } else {
>     return switch ...
> }

Done in latest update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968136129
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968134480

From liach at openjdk.org  Mon Feb 24 17:57:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
Message-ID: <EI0Eph45u6__pwU8cytpsa2JVp90WtUpuo5XJtGioOs=.efa80f00-5fea-4c08-a424-478e41018099@github.com>

On Fri, 21 Feb 2025 10:15:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 85:
> 
>> 83: 
>> 84:         @ForceInline
>> 85:         static $type$ get(VarHandle ob, Object obb, long base) {
> 
> I like this: a fast path for non-strided access, while, at the same time, reusing the impl.
> In the future we can also add another variant for when there's only one index (which is by far the most common case).

I think that would require new impl classes, as there may be invocation type clash with the existing one-offset version. And the new offset will require extra checks too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968135651

From liach at openjdk.org  Mon Feb 24 17:57:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
 <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>
Message-ID: <NNmU6UiiOQucVWSTEnjfdWOlXhh3OZlpsJMLYGhQrio=.ff688775-3a0a-4077-913c-b29d4ea18456@github.com>

On Fri, 21 Feb 2025 18:54:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one
>
> Indeed, the other cache already handles this.

Done in latest update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968136574

From liach at openjdk.org  Mon Feb 24 19:13:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 19:13:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
Message-ID: <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>

On Mon, 24 Feb 2025 11:34:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 130:
> 
>> 128:      */
>> 129:     public static VarHandle makeRawSegmentViewVarHandle(MemoryLayout enclosing, ValueLayout layout, boolean noStride, long offset) {
>> 130:         if (enclosing instanceof ValueLayout direct) {
> 
> For now the caching is ok. Moving forrward, I wonder if we shouldn't add more reuse between field var handles in cases like these:
> 
> 
> struct Point {
>    int x; int y;
> }
> 
> 
> 
> struct Tuple {
>    int u; int v;
> }
> 
> 
> E.g. if I access the first field in these two structs, then the var handle will be identical? In a way, we use the enclosing layout for two reasons:
> 
> * to determine the size `S` of the accessed memory region
> * to determine the alignment `A` of the accessed memory region
> 
> So, if the static `offset`, accessed `layout`, `S` and `A` are the same for two accesses, we should probably reuse the same var handle instance? E.g. whether we access `x` in a `Point`, or `u` in a `Tuple` makes little difference.

I think direct var handles are quite cheap already and don't really need caching. What really worth caching should be the combinators and the VH derived from those combinators.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968262515

From cjplummer at openjdk.org  Tue Feb 25 02:33:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Feb 2025 02:33:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
Message-ID: <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>

On Mon, 24 Feb 2025 12:39:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> To be sure, I did a minimal build on Linux x86_64. I set `--with-jvm-features=minimal --with-jvm-variants=minimal` for this.
> This leads to
> `JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`
> So no jvmti, to GCs except serialgc . Just C1, no C2. The 'opt-size' flag is set so the libjvm is compiled with size optimization (on Linux -Os). The other native libs (JDK native libs) still use the opt-flags they always use, as I thought.

"minimal" if a very specific footprint reducing build configuration. However, I believe what it does is enable a bunch of other individual footprint reduction features. For example, even without configuring specifically for minimal, you can optionally exclude JVMTI, or extra GCs, or C2, and I think you can optionally configure libjvm.so to be built for small size, not performance. It's not "all or none", but we don't really encourage (or officially support) selectively choosing what to exclude because it is not well tested.

> On the other hand we can achieve good performance and smaller binaries with lto (at least with gcc).

Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine. I don't know of any negative impacts with using it.

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

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

From mbaesken at openjdk.org  Tue Feb 25 09:17:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 09:17:00 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
Message-ID: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>

On Tue, 25 Feb 2025 02:31:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine.  I don't know of any negative impacts with using it.

@TheShermanTanker , @magicus  what do you think ? Should we additionally offer  LTO on library level ?
See
https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L43

Currently we only have it as an additional option for libjvm and not the other native libs .

>  I think you can optionally configure libjvm.so to be built for small size, not performance

Yes true for libjvm this is possible, it is the opt-size  part of the minimal features set
`JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`

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

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

From jwaters at openjdk.org  Tue Feb 25 09:36:54 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 09:36:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
Message-ID: <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>

On Tue, 25 Feb 2025 09:12:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine.  I don't know of any negative impacts with using it.
> 
> @TheShermanTanker , @magicus what do you think ? Should we additionally offer LTO on library level ? See https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L43
> 
> Currently we only have it as an additional option for libjvm and not the other native libs .

I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels. That said, while I'm in favour of an option that you can set to enable LTO for native JDK code (Like I have in my fork), I don't think we should do it piece by piece like this, as Kim mentioned. This probably needs to be part of a more focused effort

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

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

From mcimadamore at openjdk.org  Tue Feb 25 09:53:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <K880Nrod0JY0dzsAgXtNDc-FzTxbGAdQ0AZUshRUibo=.b002fc8f-7133-401d-a64f-5aeae7495935@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2640368169

From mcimadamore at openjdk.org  Tue Feb 25 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
Message-ID: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>

On Fri, 21 Feb 2025 22:19:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
> 
> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
> LoopOverNonConstantHeap.unsafe_loop                ...

Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2681378356

From mcimadamore at openjdk.org  Tue Feb 25 09:53:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:59 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
 <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>
Message-ID: <pDEcJ-PR_3EBt7SNwVipX52RxUv6XRv9fBkWGhEVMTU=.071d8d71-c6b4-4362-890b-9ed17cba147a@github.com>

On Mon, 24 Feb 2025 17:53:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Maybe let's leave it, at least in this round
>
> Done in latest update.

Thanks! I think it looks very good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969396191

From mcimadamore at openjdk.org  Tue Feb 25 09:54:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:54:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
 <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>
Message-ID: <7O_pS8xWC9YwStjIu2GVFpaBQS70qfXy45TbPjsVG-I=.ff32c917-5a0e-43f3-9718-e205e91ec752@github.com>

On Mon, 24 Feb 2025 19:11:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think direct var handles are quite cheap already and don't really need caching. What really worth caching should be the combinators and the VH derived from those combinators.

Right -- and one big advantage of this PR, if I'm correct, is that if you have a VH to access a single field, that will be a non-strided VH with a static offset (saved in the VH instance). So no adaptation is required (meaning no spinning of bytecodes) and, also, var handle guards will apply too. This is a very good result!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969394463

From yzheng at openjdk.org  Tue Feb 25 09:57:54 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 25 Feb 2025 09:57:54 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <cFNyh1m-RS0VWr47Rwb3_jJc06v9ggIdO0VncWO97EU=.74678cde-d835-469c-ad48-5b9331a57f50@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
 <cFNyh1m-RS0VWr47Rwb3_jJc06v9ggIdO0VncWO97EU=.74678cde-d835-469c-ad48-5b9331a57f50@github.com>
Message-ID: <1OrZ4MOSU3Xqpe-wgyPA_Wk5--ZdwVrDZn2lOJUufnk=.6f8dd7cb-d01b-4c4c-9ec0-586eb8e3878a@github.com>

On Fri, 21 Feb 2025 14:32:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename -static job to -static-libs
>
> The point about difference between `static-libs` and `static` JDK is valid. I renamed the job to `-static-libs`, and would expect #23471 to add another job like `build-linux-x64-static` that would build static JDK.
> 
> Conceptually, I have major reservations about sneaking in `static-libs-bundle` make target in the generic `build-linux` job script. It might have been OK when it was originally done, but it is IMO a hacky solution, which prompts even more hacks to workaround the first hack! See #23471. We are also "lucky" that no other jobs call into `build-linux` script with `debug-level: release`, so we are not building `static-libs-bundle` in all cross-compilation, no-pch, Zero and other jobs that only ask for `hotspot`, for example.
> 
> If we want to build `static-libs-bundle` only for Linux x64 release, the clean way to do this is to explicitly define it as separate job.
> 
> At some point in the future -- once build system catches up -- we _may_ consider adding `static-libs-bundles` into default make target list in `build-linux` / `build-windows` / etc. scripts. This would also be clean. But before that happens, the non-standard build targets have IMO no business being spliced into the generic scripts.

Hi @shipilev , we have merged the adaption in our canary tool. Could you please push a commit in this PR and see how it may trigger on our end? A trivial blank trimming or merge master would be sufficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2681389208

From pminborg at openjdk.org  Tue Feb 25 10:05:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Feb 2025 10:05:59 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 50:

> 48:     final MemoryLayout enclosing;
> 49:     /** The fixed offset value, if exists. vform decides if the fixed offset is used. */
> 50:     final long offset;

These fields are already trusted by virtue of residing in the `j.l.i` package?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969439774

From liach at openjdk.org  Tue Feb 25 13:03:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 13:03:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>
Message-ID: <J8X499VDQ_iu2bJO664CDFHGHLTHH6xfL4hyDLJQzv4=.ebcbf921-c231-4550-aa5d-dac20ecff687@github.com>

On Tue, 25 Feb 2025 10:02:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 50:
> 
>> 48:     final MemoryLayout enclosing;
>> 49:     /** The fixed offset value, if exists. vform decides if the fixed offset is used. */
>> 50:     final long offset;
> 
> These fields are already trusted by virtue of residing in the `j.l.i` package?

Yes. See https://github.com/openjdk/jdk/blob/8cfebc41dc8ec7b0d24d9c467b91de82d28b73fc/src/hotspot/share/ci/ciField.cpp#L223

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969738602

From mbaesken at openjdk.org  Tue Feb 25 13:11:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 13:11:56 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
Message-ID: <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>

On Tue, 25 Feb 2025 09:33:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels.

We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST, SIZE etc.  .

> I don't think we should do it piece by piece like this, as Kim mentioned.

I am not sure if it is currently a good idea to set LTO for all  JDK native libs; but for some it might work well and be beneficial.

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

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

From jwaters at openjdk.org  Tue Feb 25 13:16:00 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 13:16:00 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
 <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
Message-ID: <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>

On Tue, 25 Feb 2025 13:09:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels.
> 
> We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST, SIZE etc. .
> 
> > I don't think we should do it piece by piece like this, as Kim mentioned.
> 
> I am not sure if it is currently a good idea to set LTO for all JDK native libs; but for some it might work well and be beneficial.

Maybe I can prepare a changeset for this and send the diff just to get a cursory review on the changes, and see where to go from there. In my fork I have an --enable-linktime-opt option that enables LTO, so it would be an opt in change, and not an immediate change to the default linking behaviour, which I think is a no go as you mentioned

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

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

From mbaesken at openjdk.org  Tue Feb 25 13:19:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 13:19:01 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
 <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
 <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>
Message-ID: <V019J5n2eX_4A-VkpxGzUTmfHhrJ_eO9i8S2Qg0r1uw=.c99dd335-3187-4350-b74e-9c7345a63f5d@github.com>

On Tue, 25 Feb 2025 13:13:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > 
> > I am not sure if it is currently a good idea to set LTO for all JDK native libs; but for some it might work well and be beneficial.
> 
> Maybe I can prepare a changeset for this and send the diff just to get a cursory review on the changes, and see where to go from there. In my fork I have an --enable-linktime-opt option that enables LTO, so it would be an opt in change, and not an immediate change to the default linking behaviour, which I think is a no go as you mentioned

Would be good !

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

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

From ihse at openjdk.org  Tue Feb 25 14:41:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 14:41:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
 <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
Message-ID: <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>

On Fri, 21 Feb 2025 20:17:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
>> 
>> Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)
>
> Left a space and an extra note to make the comment hash more obvious.

Unless you plan to shortly push a new PR where you either enable this functionality, or remove the commented-out lines, I strongly prefer *not* to have commented-out code in the makefiles. It's not that hard to re-create these lines should they be needed. And you can always find the history in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969917926

From ihse at openjdk.org  Tue Feb 25 15:03:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:03:55 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: <2sWUsIrECG5F5g_fAVosUBjFRqFrGpcVc9xZkW0qqKQ=.abdf14dd-973b-4865-9593-5bbb36634284@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 .

Hi, sorry for my absence. Some general comments based on the discussions here:

1) As Matthias has correctly understood, there is very little known about the reasoning of the current optimization levels. They were all done much prior to me joining the build team, and the rewriting of the build system. The current "optimization levels" where the result of trying to reverse-engineering what was de facto done in the old build system, and trying to make some kind of sense out of it. I think we can safely assume that there are no real well-founded reasons for any of the current optimization flags, except for specific exceptions like Hotspot.

2) We have been very cautious in changing these flags (including how we copied the old flags precisely from the old build system), but I've more and more come to the conclusion that this conversative approach is not really helpful. Changing optimization flags is most likely not more likely to provoke unforeseen problems than upgrading the compiler, and that is something we do regularly.

3) Furthermore, it is not by any means clear that e.g. -Os on gcc 5 means even close to the same thing, in terms of generated code, as -Os on gcc 14. The *intention* is clear -- i.e. optimize for size, but I think it would be a reasonable assumption that the actually generated code (which is what we care about in the end) will not share much similarities between now and the time at which the specific compiler optimization flag was chosen.

So, in essence, I highly support Matthias's work on updating these flags. More specifically, I think it will make sense for the most cases to use SIZE instead of LOW. My general feeling, from working with other optimization efforts in the past, is that optimizing for size in most cases also renders a benefit in speed, most likely arising from the code fitting better in caches, and perhaps doing shorter jumps, so it is typically a win-win scenario.

Otoh, we could probably raise the bar and optimize for performance (HIGH or HIGHEST) on several libraries that are currently LOW, even if the consequences are less clear. Most such libraries are only heavily used in specialized scenarios. If these scenarios are *only* microbenchmarks, then we should not care. But if there is some chance that a real application has a real payload that involves stressing some native library, then I see no reason *not* to increase the optimization level, if we can prove (with microbenchmarks) that this does indeed help performance.

Then finally there is a third aspect, on top of end-user application performance and JDK footprint, and that is the build time. More optimization tend to mean longer build times. In particular, LTO has been known to be very time consuming. (This might have changed with some of the recent efforts in improving LTO; I'm not fully up to speed in that area, but in any case, we're not using any new fancy methods in the JDK as of now.)

I don't doubt that LTO will make wonders for the size, and probably performance, of any native library. But it is also likely to come at a significant increase in build time for these libraries. How much that matters on the whole -- if there are no build dependencies waiting for the library, and we can parallelize the build reasonably, and given that we do a lot more than just compile and link native libraries -- I don't know.

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

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

From ihse at openjdk.org  Tue Feb 25 15:11:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:11:57 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: <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@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 think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.

Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.

I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:


   OPT_gcc_clang := -O1, \
   OPT_microsoft := -O2. \


since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.

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

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

From ihse at openjdk.org  Tue Feb 25 15:20:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:20:55 GMT
Subject: RFR: 8346987: [lto] gtest build fails
In-Reply-To: <uQWyC1-AoOPCSP7rn3XbhrutkLIATujQPdunPHA-V34=.206739a5-ad3e-413b-a252-b3073bf99f58@github.com>
References: <uXqt6XqvXe6N1jdUm4xR3MoIjibkBUip9mKKn4LnRwc=.7edf5a95-aaf9-4536-bc85-5ebfde400465@github.com>
 <eTMS2jd_58MNXLZd-eqXCx_mU0fsqXg9N2CBjdA3YG0=.52232017-dd31-4cc2-9f51-2a98fff9ddf1@github.com>
 <-MJ1mHsvXEaIqq6IIvQQ-iDjj6g6HaTaqQrggG-Ztcw=.c11edb36-647d-4b89-a3aa-eb503d748c2f@github.com>
 <uQWyC1-AoOPCSP7rn3XbhrutkLIATujQPdunPHA-V34=.206739a5-ad3e-413b-a252-b3073bf99f58@github.com>
Message-ID: <kKBokIhV2EijDow71WghORk5E9X_nMS5jesU2Kec5-c=.6bc77f19-a187-4efe-8c28-71409f088ed0@github.com>

On Mon, 24 Feb 2025 11:38:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> I'll try to prioritize separating gtest and hotspot builds, and then it will be possible to fix this in a clean way.
>> 
>> Okay thanks, then let's wait a bit for your change  separating gtest and hotspot builds, if this helps to make the change nicer.
>
>> I'll try to prioritize separating gtest and hotspot builds, and then it will be possible to fix this in a clean way.
> 
> Hi @magicus was there some progress on this topic ?

@MBaesken @tstuefe Hi guys, sorry I've been absent for a while. :-(

I have not been making any progress on this as of my last comment. 

Regarding my plans, the JBS issue is deliberately a bit vague since I will need to do a bit of research to figure out the best way to do this. But my rough idea is that we should just split the current code into two different make targets, one that only compiles and links .o files for the "real" libjvm.so, and a separate one that compiles and links .o files for the gtest libjvm.so. This target would depend on the target producing the "real" libjvm.so, so it will have access to all .o files generated by it. I can't see any obvious reason why this would not work, but since it was never done like that from the start (which I think would have been the obvious thing to do), maybe there are some twists that I'm missing.

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

PR Comment: https://git.openjdk.org/jdk/pull/23173#issuecomment-2682345096

From ihse at openjdk.org  Tue Feb 25 15:36:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:36:39 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
Message-ID: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>

> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds. The first attempt was buggy in multiple ways and had to be backed out.
> 
> This is the description of the original bug report:
> 
> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how automatic variables without an initializer should be initialized. The default choice is "uninitialized", which is the default C/C++ behavior. Alternatives are "pattern" and "zero". For improved debugging, helping to detect uninitialized uses, the "pattern" choice should be used.

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 four commits:

 - Merge branch 'master' into auto-var-init-redo
 - Try filtering out -ftrivial-auto-var-init=pattern for libsleef. This patch is getting uglier by the minute...
 - Only add flag if it is supported
 - 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

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

Changes: https://git.openjdk.org/jdk/pull/22691/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22691&range=01
  Stats: 14 lines in 4 files changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22691/head:pull/22691

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

From ihse at openjdk.org  Tue Feb 25 15:55:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:55:10 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
Message-ID: <wFI5632EVyldJnVcuJtv2QS1LJt7FnTBZdi6pPniUdo=.b61101f4-e46d-469e-987b-fec05e62a9c8@github.com>

On Fri, 21 Feb 2025 14:24:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename -static job to -static-libs

I think this is good. The static libs situation is somewhat messy due to historical reasons, and it is not always easy to know what is the best improvement, in the short term or in the long term.

I would like to remove the old `static-libs` target and replace it with the new `static-jdk-image`, but we're not there yet. In the meantime, I think it makes sense to separate it out cleanly as you have done here.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23715#pullrequestreview-2641598006

From erikj at openjdk.org  Tue Feb 25 16:05:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Feb 2025 16:05:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <Ed1aLasBLCT-yzpycHzUzxePm9HnrKCvDq0NbJrmJmQ=.8ccd3dca-ab93-4881-8e6e-0593f3f11638@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2641639547

From erikj at openjdk.org  Tue Feb 25 16:15:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Feb 2025 16:15:02 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
 <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
Message-ID: <-376VAC0OUCmMZGo_ElGPz3DNlm6gEEMrUUVnX7CW0I=.4fb7468f-2f70-4868-8091-eadf2b940ea4@github.com>

On Tue, 25 Feb 2025 15:36:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds. The first attempt was buggy in multiple ways and had to be backed out.
>> 
>> This is the description of the original bug report:
>> 
>> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how automatic variables without an initializer should be initialized. The default choice is "uninitialized", which is the default C/C++ behavior. Alternatives are "pattern" and "zero". For improved debugging, helping to detect uninitialized uses, the "pattern" choice should be used.
>
> 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 four commits:
> 
>  - Merge branch 'master' into auto-var-init-redo
>  - Try filtering out -ftrivial-auto-var-init=pattern for libsleef. This patch is getting uglier by the minute...
>  - Only add flag if it is supported
>  - 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22691#pullrequestreview-2641670846

From shade at openjdk.org  Tue Feb 25 16:59:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Feb 2025 16:59:44 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v5]
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <63T0st4etXBuFsHPs20Po70t1NtOqN-LRm7OssX0418=.d79accb2-2be7-4c29-8d3a-e7814c70448f@github.com>

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

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

 - Merge branch 'master' into JDK-8350443-gha-split-static-libs-job
 - Rename -static job to -static-libs
 - Touch up comment
 - Upload static bundles again
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23715/files
  - new: https://git.openjdk.org/jdk/pull/23715/files/356f1fa8..35dcd17c

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

  Stats: 12717 lines in 350 files changed: 5968 ins; 5594 del; 1155 mod
  Patch: https://git.openjdk.org/jdk/pull/23715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23715/head:pull/23715

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

From shade at openjdk.org  Tue Feb 25 16:59:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Feb 2025 16:59:44 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <cFNyh1m-RS0VWr47Rwb3_jJc06v9ggIdO0VncWO97EU=.74678cde-d835-469c-ad48-5b9331a57f50@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
 <cFNyh1m-RS0VWr47Rwb3_jJc06v9ggIdO0VncWO97EU=.74678cde-d835-469c-ad48-5b9331a57f50@github.com>
Message-ID: <mPrb17rhDPBhsYJQ9Bd1yJKkmQlUuC3x9PI3WKnxZu0=.e5cff3bc-be23-4c91-a016-a0c8866c002f@github.com>

On Fri, 21 Feb 2025 14:32:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename -static job to -static-libs
>
> The point about difference between `static-libs` and `static` JDK is valid. I renamed the job to `-static-libs`, and would expect #23471 to add another job like `build-linux-x64-static` that would build static JDK.
> 
> Conceptually, I have major reservations about sneaking in `static-libs-bundle` make target in the generic `build-linux` job script. It might have been OK when it was originally done, but it is IMO a hacky solution, which prompts even more hacks to workaround the first hack! See #23471. We are also "lucky" that no other jobs call into `build-linux` script with `debug-level: release`, so we are not building `static-libs-bundle` in all cross-compilation, no-pch, Zero and other jobs that only ask for `hotspot`, for example.
> 
> If we want to build `static-libs-bundle` only for Linux x64 release, the clean way to do this is to explicitly define it as separate job.
> 
> At some point in the future -- once build system catches up -- we _may_ consider adding `static-libs-bundles` into default make target list in `build-linux` / `build-windows` / etc. scripts. This would also be clean. But before that happens, the non-standard build targets have IMO no business being spliced into the generic scripts.

> Hi @shipilev , we have merged the adaption in our canary tool. Could you please push a commit in this PR and see how it may trigger on our end? A trivial blank trimming or merge master would be sufficient.

Does a merge commit count? Just merged from master :)

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2682659187

From cjplummer at openjdk.org  Tue Feb 25 21:03:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Feb 2025 21:03:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
Message-ID: <F1iK5FJBnNn2irywrtbWqTLlm-l4ii4lpRiLUNl0hQY=.c4fa7715-95ba-49b2-b2fa-6b44ccf76285@github.com>

On Tue, 25 Feb 2025 09:14:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I think you can optionally configure libjvm.so to be built for small size, not performance
> 
> Yes true for libjvm this is possible, it is the opt-size part of the minimal features set `JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`

I wouldn't object to using -Os with the debug agent during opt-size builds.

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

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

From psandoz at openjdk.org  Tue Feb 25 22:54:00 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Feb 2025 22:54:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <yveRDsN80HbL-YFzZoAZfs6SbQDC9qycahJAIP4uu2g=.7a301862-9ea1-49fb-8f97-382686435e73@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

The read-modify-write access modes appear not to be supported for byte access to segments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683470858

From liach at openjdk.org  Tue Feb 25 23:13:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 23:13:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Indeed, the byte access currently only supports read/write (automatically aligned). No CAS or bitwise for now in FFM.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683498943

From psandoz at openjdk.org  Wed Feb 26 02:31:53 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 26 Feb 2025 02:31:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>
Message-ID: <aeGw9VVhhyH-phaFCZW6Sx4panQFmDhOpvsgZc4vz20=.c54ab713-be15-4f52-b6ac-deb5de72270a@github.com>

On Tue, 25 Feb 2025 23:11:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Indeed, the byte access currently only supports read/write (automatically aligned). No CAS or bitwise for now in FFM.

Do you know why that is so?

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683738533

From liach at openjdk.org  Wed Feb 26 03:04:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 03:04:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
 <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
Message-ID: <qCGijw7AEXWCGkcMYoSnGdaKTLq2xf9-Wwhba7hvSJ4=.3ced0e14-a52c-443e-814d-fbb4735ea99d@github.com>

On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
>> 
>> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
>> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
>> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
>> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
>> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
>> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
>> Loo...
>
> Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

Unfortunately no. I don't really know about the Foreign Memory API as I only started to investigate its performance bottlenecks recently. @mcimadamore or @JornVernee were more involved in the development and likely know better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683776781

From fthevene at redhat.com  Wed Feb 26 08:52:44 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Wed, 26 Feb 2025 09:52:44 +0100
Subject: [Proposal] Add code signing on Windows to the JDK build system
Message-ID: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>

Hi,

I would like to start a discussion about adding built-in support for 
code signing native executable file and dynamic library on Windows 
directly as part of the JDK build, in a similar fashion to what already 
exists for macOS.

Most, if not all vendors already ensure that every native executable 
files and dynamic libraries that are part of the binary builds of 
OpenJDK that they distribute to their customers for the Windows platform 
are digitally signed using a set of Microsoft APIs and tools called 
Authenticode[1].

Since this is not a part of the existing JDK build system, however, this 
means that each vendor has had to come up with their own way to 
integrate the code signing step into their build pipeline.
As the shape of the JDK binary deliverable evolved to accommodate 
features like modules, signing binaries as an after-the-fact process has 
gradually become more complicated and error prone.

For instance, with the introduction of JEP 493 (Linking Run-Time Images 
without JMODs)[2], adding a digital signature to files after jlink runs 
as part of the build to create the JDK image when the new 
'--generate-linkable-runtime' feature is enabled will cause any 
subsequent uses of jlink from this image to fail with a "Error:<xxxx> 
has been modified" error.

The solution to that particular problem is to ensure that the signature 
is applied before jlink generates the checksums it will later use to 
detect , and I believe the best way to achieve that is to integrate code 
signing as an option in the jdk build process.

This would also offer vendors who decide to opt into using this new 
feature to potentially simplify their overall build process.
For instance, this could get rid of extra steps such as filtering out 
dlls that are part of the bundle but were not built as part of the jdk 
(e.g. the Microsoft C and C++ runtime redistributables), or making sure 
that 'exe' and 'dll' files packaged in the .jmod files are also signed.

As a stated before a very similar option already exists for code signing 
on the macOS platform, which further reinforce my thinking that such a 
feature would make sense for Windows as well.

I have drafted a prototype for this and would be happy to create JBS 
issue and submit a PR to move this forward, provided there is interest.

Thanks,
Frederic Thevenet (fthevenet)

[1] 
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
[2] https://openjdk.org/jeps/493


From ihse at openjdk.org  Wed Feb 26 12:16:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 26 Feb 2025 12:16:07 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
Message-ID: <fjmsioELjCrHNs7atVhGVhXz8-CQ6fsfbAEpSn5OMes=.4b11d868-945d-49e1-927a-df6225afb2bb@github.com>

On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>  - adapt changes to the ancient awk on MacOS
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - indented the comment
>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>  - lowercased Jtreg. fixed typos in the comment
>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1b30c128...6af586a2

The GHA tests all look failed since `.github/scripts/gen-test-summary.sh` does not know about this new output format. The fix should be fairly trivial, but a somewhat more interesting question is if the number of skipped tests should be reported to the user, not as an error but as a warning or informational message. On the one hand, it seems prudent to inform users that not all tests where run as requested, but on the other hand, most users likely don't care, they just want to run "tier1" with whatever it includes, and printing the number of skipped tests for all test runs will likely only produce clutter and noise.

Actually, I think I answered myself. :-) We should not inform about skipped tests in GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/22245#issuecomment-2684787926

From mbaesken at openjdk.org  Wed Feb 26 13:27:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Feb 2025 13:27:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
Message-ID: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>

On Tue, 25 Feb 2025 15:09:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.

Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
Seems I can edit the pages there but not create a new one , can you !?

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

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

From hannesw at openjdk.org  Wed Feb 26 14:12:12 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Feb 2025 14:12:12 GMT
Subject: RFR: 8287749: Re-enable javadoc -serialwarn option
Message-ID: <B9E-ag7-ljLl2Zuq60uZt72GtSHVC5TyCHKkjLrM8LU=.a62ed30c-6150-4e01-b7e2-7e835278e5a5@github.com>

Please review a simple build change to re-enable the `-serialwarn` javadoc option for normal and reference API docs. The option was removed in [JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings for missing `@serial` tags which have since been added in [JDK-8286931](https://bugs.openjdk.org/browse/JDK-8286931). 

I tested normal and reference docs builds, both run without warning and the generated documentation is unchanged. The `@serial` tag in the Exception template is required and also does not affect javadoc output.

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

Commit messages:
 - 8287749: Re-enable javadoc -serialwarn option

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

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

From erik.joelsson at oracle.com  Wed Feb 26 14:29:18 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 26 Feb 2025 06:29:18 -0800
Subject: [Proposal] Add code signing on Windows to the JDK build system
In-Reply-To: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
Message-ID: <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>

Hello,

I think this is a reasonable idea and you are welcome to implement it. 
At Oracle we have been solving this using custom extension makefiles. 
That will unfortunately not change with this proposal as our signing 
process does not involve direct access to the native tools of the OS. 
Perhaps this implementation could be made plug-able enough so that we 
could leverage it, I'm not sure. What I'm trying to say is that we are 
not against this, but we are also not inclined to invest resources into it.

/Erik

On 2/26/25 12:52 AM, Frederic Thevenet wrote:
> Hi,
>
> I would like to start a discussion about adding built-in support for 
> code signing native executable file and dynamic library on Windows 
> directly as part of the JDK build, in a similar fashion to what 
> already exists for macOS.
>
> Most, if not all vendors already ensure that every native executable 
> files and dynamic libraries that are part of the binary builds of 
> OpenJDK that they distribute to their customers for the Windows 
> platform are digitally signed using a set of Microsoft APIs and tools 
> called Authenticode[1].
>
> Since this is not a part of the existing JDK build system, however, 
> this means that each vendor has had to come up with their own way to 
> integrate the code signing step into their build pipeline.
> As the shape of the JDK binary deliverable evolved to accommodate 
> features like modules, signing binaries as an after-the-fact process 
> has gradually become more complicated and error prone.
>
> For instance, with the introduction of JEP 493 (Linking Run-Time 
> Images without JMODs)[2], adding a digital signature to files after 
> jlink runs as part of the build to create the JDK image when the new 
> '--generate-linkable-runtime' feature is enabled will cause any 
> subsequent uses of jlink from this image to fail with a "Error:<xxxx> 
> has been modified" error.
>
> The solution to that particular problem is to ensure that the 
> signature is applied before jlink generates the checksums it will 
> later use to detect , and I believe the best way to achieve that is to 
> integrate code signing as an option in the jdk build process.
>
> This would also offer vendors who decide to opt into using this new 
> feature to potentially simplify their overall build process.
> For instance, this could get rid of extra steps such as filtering out 
> dlls that are part of the bundle but were not built as part of the jdk 
> (e.g. the Microsoft C and C++ runtime redistributables), or making 
> sure that 'exe' and 'dll' files packaged in the .jmod files are also 
> signed.
>
> As a stated before a very similar option already exists for code 
> signing on the macOS platform, which further reinforce my thinking 
> that such a feature would make sense for Windows as well.
>
> I have drafted a prototype for this and would be happy to create JBS 
> issue and submit a PR to move this forward, provided there is interest.
>
> Thanks,
> Frederic Thevenet (fthevenet)
>
> [1] 
> https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
> [2] https://openjdk.org/jeps/493
>

From erikj at openjdk.org  Wed Feb 26 14:33:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 26 Feb 2025 14:33:53 GMT
Subject: RFR: 8287749: Re-enable javadoc -serialwarn option
In-Reply-To: <B9E-ag7-ljLl2Zuq60uZt72GtSHVC5TyCHKkjLrM8LU=.a62ed30c-6150-4e01-b7e2-7e835278e5a5@github.com>
References: <B9E-ag7-ljLl2Zuq60uZt72GtSHVC5TyCHKkjLrM8LU=.a62ed30c-6150-4e01-b7e2-7e835278e5a5@github.com>
Message-ID: <_SDLkylm9iLVE8V0MWLexFGOypFPHov5WqsSR1a7mPU=.6a406d4f-40db-4cc2-9922-41bb64a9ad2d@github.com>

On Wed, 26 Feb 2025 14:06:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple build change to re-enable the `-serialwarn` javadoc option for normal and reference API docs. The option was removed in [JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings for missing `@serial` tags which have since been added in [JDK-8286931](https://bugs.openjdk.org/browse/JDK-8286931). 
> 
> I tested normal and reference docs builds, both run without warning and the generated documentation is unchanged. The `@serial` tag in the Exception template is required and also does not affect javadoc output.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23802#pullrequestreview-2644723376

From yzheng at openjdk.org  Wed Feb 26 14:42:06 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 26 Feb 2025 14:42:06 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v5]
In-Reply-To: <63T0st4etXBuFsHPs20Po70t1NtOqN-LRm7OssX0418=.d79accb2-2be7-4c29-8d3a-e7814c70448f@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <63T0st4etXBuFsHPs20Po70t1NtOqN-LRm7OssX0418=.d79accb2-2be7-4c29-8d3a-e7814c70448f@github.com>
Message-ID: <Pf8ZuxnZS8LnznM7LSbc18xsYl6594mEsLf5EWWvXSI=.1aa410e8-74ac-412d-ba2e-819cc1dded9f@github.com>

On Tue, 25 Feb 2025 16:59:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8350443-gha-split-static-libs-job
>  - Rename -static job to -static-libs
>  - Touch up comment
>  - Upload static bundles again
>  - Fix

Graal's canary tool now works with this change!

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23715#pullrequestreview-2644746015

From hannesw at openjdk.org  Wed Feb 26 15:02:11 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Feb 2025 15:02:11 GMT
Subject: Integrated: 8287749: Re-enable javadoc -serialwarn option
In-Reply-To: <B9E-ag7-ljLl2Zuq60uZt72GtSHVC5TyCHKkjLrM8LU=.a62ed30c-6150-4e01-b7e2-7e835278e5a5@github.com>
References: <B9E-ag7-ljLl2Zuq60uZt72GtSHVC5TyCHKkjLrM8LU=.a62ed30c-6150-4e01-b7e2-7e835278e5a5@github.com>
Message-ID: <6jjipj6eUNRV469cMEJXmEtI0I0s4ZUfy4Od3bRNUcc=.4fadda83-2db4-48df-a96a-f87f029aa150@github.com>

On Wed, 26 Feb 2025 14:06:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple build change to re-enable the `-serialwarn` javadoc option for normal and reference API docs. The option was removed in [JDK-8252717](https://bugs.openjdk.org/browse/JDK-8252717) to avoid warnings for missing `@serial` tags which have since been added in [JDK-8286931](https://bugs.openjdk.org/browse/JDK-8286931). 
> 
> I tested normal and reference docs builds, both run without warning and the generated documentation is unchanged. The `@serial` tag in the Exception template is required and also does not affect javadoc output.

This pull request has now been integrated.

Changeset: 27317123
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2731712383937ce7213c4c2b89f8c041708a3f90
Stats:     5 lines in 2 files changed: 2 ins; 0 del; 3 mod

8287749: Re-enable javadoc -serialwarn option

Reviewed-by: erikj

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

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

From shade at openjdk.org  Wed Feb 26 15:04:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 15:04:05 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <oPcAJyzziw6giVs8TJMUDlNgGcgyEVPV6yFKYHQqakk=.6b8a2778-8058-401d-8e6a-833ae7493122@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
 <oPcAJyzziw6giVs8TJMUDlNgGcgyEVPV6yFKYHQqakk=.6b8a2778-8058-401d-8e6a-833ae7493122@github.com>
Message-ID: <J8xlJG3x6AC9GA-P7wLZK9qMwrdmLdHb9hDi2_KXD-k=.57c21e06-6d22-4595-bf81-b6fbb0004a38@github.com>

On Fri, 21 Feb 2025 21:52:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename -static job to -static-libs
>
> Yes, we should distinguish between `static-libs` and `static` JDK. Currently, we refer `static` JDK as a 'fully' statically linked `java` launcher, plus `lib/modules` and other JDK resource files needed for runtime. 
> 
> For longer term, including `static-libs-bundles` by default may be what we want. For example, in our current hermetic Java prototype, we release a regular JDK + static-libs. The final hermetic Java image creation step builds the single image using:
> 
> - launcher (code)
> - JDK/hostpot `static-libs`
> - lib/modules
> - JDK resource files
> - application classes and resources
> - application natives and dependencies
> 
> During the image creation process, a launcher executable is linked using the launcher `.o` file, (needed) JDK/hotspot static libs, application natives and dependencies (in `.o` files or static libraries).

Great! Let's integrate and unblock @jianglizhou's work.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2685324620

From shade at openjdk.org  Wed Feb 26 15:04:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 15:04:06 GMT
Subject: Integrated: 8350443: GHA: Split static-libs-bundles into a separate
 job
In-Reply-To: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
Message-ID: <yVg8X4e_hg7IM4fJHjPcsHZBfwJylH2bCUtomNU1c0M=.06bfc6dd-c03a-4010-9f36-bc5dd14c66d6@github.com>

On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
> 
> This effectively reverts parts of the original change, and does a few modifications:
>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
> 
> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
> 
> I did a partial GHA run already, and I expect full run to complete without errors.
> 
> Testing:
>  - [x] GHA

This pull request has now been integrated.

Changeset: bd112c4f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd112c4fab8c6b6a8181d4629009b6cb408727a1
Stats:     39 lines in 3 files changed: 26 ins; 8 del; 5 mod

8350443: GHA: Split static-libs-bundles into a separate job

Reviewed-by: ihse, yzheng

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

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

From shade at openjdk.org  Wed Feb 26 15:05:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 15:05:05 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <rPwmv6nli7s5b-ThGFeh0ughXzchNy3a8HMoVPkQiJY=.8e43aedb-ddf1-4258-aa31-3afd8eaa26e0@github.com>

On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

#23715 should now be in. Now you can just add a clean separate job for this, like this one:
https://github.com/openjdk/jdk/blob/bd112c4fab8c6b6a8181d4629009b6cb408727a1/.github/workflows/main.yml#L228-L245

And then you don't need a whole new script for static-jdk build.

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2685333386

From jvernee at openjdk.org  Wed Feb 26 17:02:00 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:02:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
Message-ID: <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>

On Fri, 21 Feb 2025 10:05:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:
> 
>> 148:         String methodName = value.methodName();
>> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
>> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;
> 
> Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)

TBH, I thought that resolving the member name would implicitly initialize the class

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1971985978

From liach at openjdk.org  Wed Feb 26 17:05:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 17:05:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
 <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>
Message-ID: <asdX2j19MxYN0Vpo45UQq7eRY-d-GF3JcDi0GfhL770=.756bafa5-49e6-444e-8b91-60682b1c232a@github.com>

On Wed, 26 Feb 2025 16:59:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:
>> 
>>> 148:         String methodName = value.methodName();
>>> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
>>> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;
>> 
>> Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)
>
> TBH, I thought that resolving the member name would implicitly initialize the class

I think the lack of initialization is WAI - DMH explicitly has an initialization barrier form. This form requires the invoked static method to be resolved, yet it does not initialize the declaring class until the initialization barrier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1971991806

From jvernee at openjdk.org  Wed Feb 26 17:21:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:21:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:

> 81:                     bb.unsafeGetBase(),
> 82:                     offset(bb, base, offset),
> 83:                     handle.be);

Why do we not have a call to `convEndian` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972019170

From jvernee at openjdk.org  Wed Feb 26 17:26:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:26:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
Message-ID: <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>

On Wed, 26 Feb 2025 17:22:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:
> 
>> 214:         } else {
>> 215:             // simpler adaptation
>> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)
> 
> Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.

I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972026669

From jvernee at openjdk.org  Wed Feb 26 17:26:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:26:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:

> 214:         } else {
> 215:             // simpler adaptation
> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)

Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972024703

From jvernee at openjdk.org  Wed Feb 26 17:30:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:30:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 331:

> 329: 
> 330:     @ForceInline
> 331:     public static int unboxSegment32(MemorySegment segment) {

Could you add a comment here:
Suggestion:

    public static int unboxSegment32(MemorySegment segment) {
        // this cast to 'int' is safe, because we only call this method on 32-bit platforms, where we know the address of a segment is truncated to 32-bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972037179

From jvernee at openjdk.org  Wed Feb 26 17:41:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:41:14 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <pUg1f70Sd3w2EGZI1gmxCyCM-7ShL2HkdCWnDHhPpE0=.25d93bb8-0cbe-4ab2-889b-c4e78f77c6d6@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:

> 72:             return ret;
> 73:         return computeFilterHandle(index);
> 74:     }

Why is this using an array, instead of just having 3 fields?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972039341

From jiangli at openjdk.org  Wed Feb 26 17:52:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 17:52:57 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v2]
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

Jiangli Zhou 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 nine additional commits since the last revision:

 - Rename build-linux-x64-static job to build-linux-x64-static-jdk. Remove build-linux-static.yml.
 - Merge branch 'master' into JDK-8349399
 - Set matrix.
 - Remove debug build for now.
 - Set debug-levels to "release".
 - Set debug-levels to "debug".
 - Add build-linux-static.yml.
 - Add build-linux-static.yml.
 - Add build-linux-x64-static build job in GHA.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23471/files
  - new: https://git.openjdk.org/jdk/pull/23471/files/503285b8..385c0bce

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

  Stats: 39058 lines in 1384 files changed: 22139 ins; 11207 del; 5712 mod
  Patch: https://git.openjdk.org/jdk/pull/23471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23471/head:pull/23471

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

From shade at openjdk.org  Wed Feb 26 18:03:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 18:03:01 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v2]
In-Reply-To: <z-n5RVJ9g2WKGYTcpap0mx6i3-BlaMu_dVpSR64Muvs=.15e9f295-620c-447f-87a8-0061d51efd99@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>
 <z-n5RVJ9g2WKGYTcpap0mx6i3-BlaMu_dVpSR64Muvs=.15e9f295-620c-447f-87a8-0061d51efd99@github.com>
Message-ID: <mYOfnzJ3gn4moujdDJWsQAeiiHH5zX5LGjTqicKIokk=.ea4fdd1d-e5fb-4ad2-ad88-ce5305fce6f4@github.com>

On Wed, 26 Feb 2025 17:58:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou 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 nine additional commits since the last revision:
>> 
>>  - Rename build-linux-x64-static job to build-linux-x64-static-jdk. Remove build-linux-static.yml.
>>  - Merge branch 'master' into JDK-8349399
>>  - Set matrix.
>>  - Remove debug build for now.
>>  - Set debug-levels to "release".
>>  - Set debug-levels to "debug".
>>  - Add build-linux-static.yml.
>>  - Add build-linux-static.yml.
>>  - Add build-linux-x64-static build job in GHA.
>
> .github/workflows/main.yml line 171:
> 
>> 169:     if: needs.prepare.outputs.linux-x64 == 'true'
>> 170: 
>> 171:   build-linux-x64-static-jdk:
> 
> Move this closer to `build-linux-x64-static-libs`? These are somewhat related, at least in their need for `debug-levels: release`. Probably copy a comment about debug-level there.

Also maybe just `build-linux-x64-static`? `-jdk` feels a bit redundant. I see you had it before, would you still prefer `...-static-jdk`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972094716

From shade at openjdk.org  Wed Feb 26 18:03:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 18:03:00 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v2]
In-Reply-To: <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>
Message-ID: <z-n5RVJ9g2WKGYTcpap0mx6i3-BlaMu_dVpSR64Muvs=.15e9f295-620c-447f-87a8-0061d51efd99@github.com>

On Wed, 26 Feb 2025 17:52:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> Jiangli Zhou 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 nine additional commits since the last revision:
> 
>  - Rename build-linux-x64-static job to build-linux-x64-static-jdk. Remove build-linux-static.yml.
>  - Merge branch 'master' into JDK-8349399
>  - Set matrix.
>  - Remove debug build for now.
>  - Set debug-levels to "release".
>  - Set debug-levels to "debug".
>  - Add build-linux-static.yml.
>  - Add build-linux-static.yml.
>  - Add build-linux-x64-static build job in GHA.

Cool, one nit:

.github/workflows/main.yml line 171:

> 169:     if: needs.prepare.outputs.linux-x64 == 'true'
> 170: 
> 171:   build-linux-x64-static-jdk:

Move this closer to `build-linux-x64-static-libs`? These are somewhat related, at least in their need for `debug-levels: release`. Probably copy a comment about debug-level there.

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

PR Review: https://git.openjdk.org/jdk/pull/23471#pullrequestreview-2645368779
PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972091928

From jiangli at openjdk.org  Wed Feb 26 18:13:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 18:13:58 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v2]
In-Reply-To: <mYOfnzJ3gn4moujdDJWsQAeiiHH5zX5LGjTqicKIokk=.ea4fdd1d-e5fb-4ad2-ad88-ce5305fce6f4@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>
 <z-n5RVJ9g2WKGYTcpap0mx6i3-BlaMu_dVpSR64Muvs=.15e9f295-620c-447f-87a8-0061d51efd99@github.com>
 <mYOfnzJ3gn4moujdDJWsQAeiiHH5zX5LGjTqicKIokk=.ea4fdd1d-e5fb-4ad2-ad88-ce5305fce6f4@github.com>
Message-ID: <UNIhjs9jUzBPawJZtt7Vqdq6dvJNwfb_QIBUo7edSPI=.ad93b1b4-8b7f-4443-ae01-af2492da4d9f@github.com>

On Wed, 26 Feb 2025 17:59:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> .github/workflows/main.yml line 171:
>> 
>>> 169:     if: needs.prepare.outputs.linux-x64 == 'true'
>>> 170: 
>>> 171:   build-linux-x64-static-jdk:
>> 
>> Move this closer to `build-linux-x64-static-libs`? These are somewhat related, at least in their need for `debug-levels: release`. Probably copy a comment about debug-level there.
>
> Also maybe just `build-linux-x64-static`? `-jdk` feels a bit redundant. I see you had it before, would you still prefer `...-static-jdk`?

Thanks for the quick look, @shipilev! Also, thanks for separating the static-libs-bundle with https://github.com/openjdk/jdk/pull/23715. I haven't responded to your earlier comment as I wanted to wait for the GHA testing results.

I renamed to `...-static-jdk` to be more consistent with the new `...-static-libs` job. `build-linux-x64-static` still sounds fine to me, I'll rename it back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972109329

From jiangli at openjdk.org  Wed Feb 26 18:24:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 18:24:13 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v3]
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <GvrK5bB5jSbbwzRHXMZSYT6-dw6SwrAitDZUCOays40=.540d3b31-7051-40e0-b817-530ae90aa54c@github.com>

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

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

  Rename build-linux-x64-static-jdk back to build-linux-x64-static and move close to build-linux-x64-static-libs, for addressing shipilev's suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23471/files
  - new: https://git.openjdk.org/jdk/pull/23471/files/385c0bce..6d637c97

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

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

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

From jiangli at openjdk.org  Wed Feb 26 18:24:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 18:24:13 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v2]
In-Reply-To: <mYOfnzJ3gn4moujdDJWsQAeiiHH5zX5LGjTqicKIokk=.ea4fdd1d-e5fb-4ad2-ad88-ce5305fce6f4@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <TQcOKP6RJxJR1PjSLT6DTOFj9dwOterrkMffX8HvTUY=.0d26166c-bf35-418d-bd02-22c3d0dcd5a9@github.com>
 <z-n5RVJ9g2WKGYTcpap0mx6i3-BlaMu_dVpSR64Muvs=.15e9f295-620c-447f-87a8-0061d51efd99@github.com>
 <mYOfnzJ3gn4moujdDJWsQAeiiHH5zX5LGjTqicKIokk=.ea4fdd1d-e5fb-4ad2-ad88-ce5305fce6f4@github.com>
Message-ID: <EP5uSAOvSGibBWtMdvnbRiCQCd8JMcGl9jIeumaNFNI=.91dfcd9a-109d-4afc-b28d-7499b4282b26@github.com>

On Wed, 26 Feb 2025 17:59:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> .github/workflows/main.yml line 171:
>> 
>>> 169:     if: needs.prepare.outputs.linux-x64 == 'true'
>>> 170: 
>>> 171:   build-linux-x64-static-jdk:
>> 
>> Move this closer to `build-linux-x64-static-libs`? These are somewhat related, at least in their need for `debug-levels: release`. Probably copy a comment about debug-level there.
>
> Also maybe just `build-linux-x64-static`? `-jdk` feels a bit redundant. I see you had it before, would you still prefer `...-static-jdk`?

@shipilev Updated based on your suggestions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972122837

From jiangli at openjdk.org  Wed Feb 26 18:26:59 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 18:26:59 GMT
Subject: RFR: 8350443: GHA: Split static-libs-bundles into a separate job
 [v4]
In-Reply-To: <J8xlJG3x6AC9GA-P7wLZK9qMwrdmLdHb9hDi2_KXD-k=.57c21e06-6d22-4595-bf81-b6fbb0004a38@github.com>
References: <pJxeWiv0u44hYrQ1Vxl1-71Mt8UB3AakGtSXrgGuaY8=.1581c0f5-1923-439b-9c57-d810b1176f74@github.com>
 <_xQn06_pNVpr5I0uKmBrJe_YgRDoeP8CyzPq3x3GNLE=.720ba8e9-86e4-4159-a211-dcf765e507c8@github.com>
 <oPcAJyzziw6giVs8TJMUDlNgGcgyEVPV6yFKYHQqakk=.6b8a2778-8058-401d-8e6a-833ae7493122@github.com>
 <J8xlJG3x6AC9GA-P7wLZK9qMwrdmLdHb9hDi2_KXD-k=.57c21e06-6d22-4595-bf81-b6fbb0004a38@github.com>
Message-ID: <KJcD3YosaX1ca0OVXqgwAO-pYXs6ka54RDPIznEc38M=.0657801b-ca8a-4cfb-aacd-49ada6f81353@github.com>

On Wed, 26 Feb 2025 14:59:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, we should distinguish between `static-libs` and `static` JDK. Currently, we refer `static` JDK as a 'fully' statically linked `java` launcher, plus `lib/modules` and other JDK resource files needed for runtime. 
>> 
>> For longer term, including `static-libs-bundles` by default may be what we want. For example, in our current hermetic Java prototype, we release a regular JDK + static-libs. The final hermetic Java image creation step builds the single image using:
>> 
>> - launcher (code)
>> - JDK/hostpot `static-libs`
>> - lib/modules
>> - JDK resource files
>> - application classes and resources
>> - application natives and dependencies
>> 
>> During the image creation process, a launcher executable is linked using the launcher `.o` file, (needed) JDK/hotspot static libs, application natives and dependencies (in `.o` files or static libraries).
>
> Great! Let's integrate and unblock @jianglizhou's work.

Thank you, @shipilev!

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2685854569

From fthevene at redhat.com  Wed Feb 26 18:40:22 2025
From: fthevene at redhat.com (Frederic Thevenet)
Date: Wed, 26 Feb 2025 19:40:22 +0100
Subject: [Proposal] Add code signing on Windows to the JDK build system
In-Reply-To: <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>
References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
 <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>
Message-ID: <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com>

Hi Erik,

Thanks for your comments.

As a matter of fact, we at Red Hat also face similar constraints that 
prevent us from being able to sign the files on the machine that build 
them (and I suspect this is quite common-place).

My initial idea to accommodate that is to have the jdk build invoke a 
user supplied script (via a --with configure argument) rather than 
having it call signtool directly, so as to provide a way for everyone to 
easily plug their specific configuration and logic (in our case, the 
script uploads the file to sign to the signing machine and download it 
once it is done, in a synchronous fashion).

In effect, it's just a hook that is invoked after the native linker has 
been called.

I have created a PR[1] where you can see what I've done in details.

Thanks,
Frederic

[1] https://github.com/openjdk/jdk/pull/23807

On 26/02/2025 15:29, Erik Joelsson wrote:
> Hello,
>
> I think this is a reasonable idea and you are welcome to implement it. 
> At Oracle we have been solving this using custom extension makefiles. 
> That will unfortunately not change with this proposal as our signing 
> process does not involve direct access to the native tools of the OS. 
> Perhaps this implementation could be made plug-able enough so that we 
> could leverage it, I'm not sure. What I'm trying to say is that we are 
> not against this, but we are also not inclined to invest resources 
> into it.
>
> /Erik
>
> On 2/26/25 12:52 AM, Frederic Thevenet wrote:
>> Hi,
>>
>> I would like to start a discussion about adding built-in support for 
>> code signing native executable file and dynamic library on Windows 
>> directly as part of the JDK build, in a similar fashion to what 
>> already exists for macOS.
>>
>> Most, if not all vendors already ensure that every native executable 
>> files and dynamic libraries that are part of the binary builds of 
>> OpenJDK that they distribute to their customers for the Windows 
>> platform are digitally signed using a set of Microsoft APIs and tools 
>> called Authenticode[1].
>>
>> Since this is not a part of the existing JDK build system, however, 
>> this means that each vendor has had to come up with their own way to 
>> integrate the code signing step into their build pipeline.
>> As the shape of the JDK binary deliverable evolved to accommodate 
>> features like modules, signing binaries as an after-the-fact process 
>> has gradually become more complicated and error prone.
>>
>> For instance, with the introduction of JEP 493 (Linking Run-Time 
>> Images without JMODs)[2], adding a digital signature to files after 
>> jlink runs as part of the build to create the JDK image when the new 
>> '--generate-linkable-runtime' feature is enabled will cause any 
>> subsequent uses of jlink from this image to fail with a "Error:<xxxx> 
>> has been modified" error.
>>
>> The solution to that particular problem is to ensure that the 
>> signature is applied before jlink generates the checksums it will 
>> later use to detect , and I believe the best way to achieve that is 
>> to integrate code signing as an option in the jdk build process.
>>
>> This would also offer vendors who decide to opt into using this new 
>> feature to potentially simplify their overall build process.
>> For instance, this could get rid of extra steps such as filtering out 
>> dlls that are part of the bundle but were not built as part of the 
>> jdk (e.g. the Microsoft C and C++ runtime redistributables), or 
>> making sure that 'exe' and 'dll' files packaged in the .jmod files 
>> are also signed.
>>
>> As a stated before a very similar option already exists for code 
>> signing on the macOS platform, which further reinforce my thinking 
>> that such a feature would make sense for Windows as well.
>>
>> I have drafted a prototype for this and would be happy to create JBS 
>> issue and submit a PR to move this forward, provided there is interest.
>>
>> Thanks,
>> Frederic Thevenet (fthevenet)
>>
>> [1] 
>> https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
>> [2] https://openjdk.org/jeps/493
>>
>


From ihse at openjdk.org  Wed Feb 26 19:10:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 26 Feb 2025 19:10:04 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
Message-ID: <4Gwqsj45uGnAXA4RTeCaeqjspwLHW-fGkW-b0GdyRA8=.e541f5a8-6975-458a-808c-202a8f01397c@github.com>

On Wed, 19 Feb 2025 09:55:42 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>  - adapt changes to the ancient awk on MacOS
>  - Merge branch 'master' into 8343832_enhance_test_summary
>  - indented the comment
>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>  - lowercased Jtreg. fixed typos in the comment
>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/47eb675a...6af586a2

Actually, my assessment was wrong -- it is not the GHA script that is the cause of failure. Instead, it was the changes in RunTests.gmk that were not complete. They tried to detect if there were any errors by comparing the number of successful tests with the total number of tests, but this is no longer an uphold invariant. Another side effect of this was that even when run locally, tests suites with passed tests would be marked as failed.

It was a bit tricky to describe what was needed for this, so I made a patch at 
https://github.com/openjdk/jdk/commit/6784dea42c60b720027b291dfd8263ad175b4ab0. This is currently running in GHA at https://github.com/magicus/jdk/actions/runs/13551422706, but I expect it to pass, since the script behaves properly local on my computer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22245#issuecomment-2685952760

From erik.joelsson at oracle.com  Wed Feb 26 19:46:45 2025
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 26 Feb 2025 11:46:45 -0800
Subject: [Proposal] Add code signing on Windows to the JDK build system
In-Reply-To: <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com>
References: <5078ca02-b6af-48af-95ba-98b3ab3957dc@redhat.com>
 <b85b8665-2d52-4aa6-ad70-94298cbf10f4@oracle.com>
 <79bc54ec-fd5d-4803-914d-01c64ef88a98@redhat.com>
Message-ID: <1f1fd802-72e0-4b27-9a77-9d9ed913caf3@oracle.com>

On 2/26/25 10:40 AM, Frederic Thevenet wrote:
> Hi Erik,
>
> Thanks for your comments.
>
> As a matter of fact, we at Red Hat also face similar constraints that 
> prevent us from being able to sign the files on the machine that build 
> them (and I suspect this is quite common-place).
>
> My initial idea to accommodate that is to have the jdk build invoke a 
> user supplied script (via a --with configure argument) rather than 
> having it call signtool directly, so as to provide a way for everyone 
> to easily plug their specific configuration and logic (in our case, 
> the script uploads the file to sign to the signing machine and 
> download it once it is done, in a synchronous fashion).
>
> In effect, it's just a hook that is invoked after the native linker 
> has been called.
>
> I have created a PR[1] where you can see what I've done in details.

That's a small and unintrusive solution. Our solution is a lot more 
involved as I figured I wanted to expose a set of top level "phase" 
targets for signing for each module, so that building libs or launchers 
can be done independently from signing (e.g. java.base-libs, 
java.base-launchers and java.base-sign). This necessitates a separate 
set of output directories for signed libs and signed launchers, where we 
first build like normal to the regular output dirs and then the sign 
target copies and signs binaries into the *-signed outputdirs, and when 
building jmods, we need to pick up the files from those *-signed 
directories. It's quite messy, so I've kept it all in our internal 
makefile extensions. I'm also questioning the usefulness of this 
flexibility given how much complexity it adds, so your proposal is 
probably preferred.

That said, I'm wondering if we could make it a bit more generic and not 
define it as "windows" specific? Then perhaps bake in the macos signing 
logic into this as well. The default implementation could be using the 
native OS tools while there is a configure option to completely replace it.

/Erik

>
> Thanks,
> Frederic
>
> [1] https://github.com/openjdk/jdk/pull/23807
>
> On 26/02/2025 15:29, Erik Joelsson wrote:
>> Hello,
>>
>> I think this is a reasonable idea and you are welcome to implement 
>> it. At Oracle we have been solving this using custom extension 
>> makefiles. That will unfortunately not change with this proposal as 
>> our signing process does not involve direct access to the native 
>> tools of the OS. Perhaps this implementation could be made plug-able 
>> enough so that we could leverage it, I'm not sure. What I'm trying to 
>> say is that we are not against this, but we are also not inclined to 
>> invest resources into it.
>>
>> /Erik
>>
>> On 2/26/25 12:52 AM, Frederic Thevenet wrote:
>>> Hi,
>>>
>>> I would like to start a discussion about adding built-in support for 
>>> code signing native executable file and dynamic library on Windows 
>>> directly as part of the JDK build, in a similar fashion to what 
>>> already exists for macOS.
>>>
>>> Most, if not all vendors already ensure that every native executable 
>>> files and dynamic libraries that are part of the binary builds of 
>>> OpenJDK that they distribute to their customers for the Windows 
>>> platform are digitally signed using a set of Microsoft APIs and 
>>> tools called Authenticode[1].
>>>
>>> Since this is not a part of the existing JDK build system, however, 
>>> this means that each vendor has had to come up with their own way to 
>>> integrate the code signing step into their build pipeline.
>>> As the shape of the JDK binary deliverable evolved to accommodate 
>>> features like modules, signing binaries as an after-the-fact process 
>>> has gradually become more complicated and error prone.
>>>
>>> For instance, with the introduction of JEP 493 (Linking Run-Time 
>>> Images without JMODs)[2], adding a digital signature to files after 
>>> jlink runs as part of the build to create the JDK image when the new 
>>> '--generate-linkable-runtime' feature is enabled will cause any 
>>> subsequent uses of jlink from this image to fail with a 
>>> "Error:<xxxx> has been modified" error.
>>>
>>> The solution to that particular problem is to ensure that the 
>>> signature is applied before jlink generates the checksums it will 
>>> later use to detect , and I believe the best way to achieve that is 
>>> to integrate code signing as an option in the jdk build process.
>>>
>>> This would also offer vendors who decide to opt into using this new 
>>> feature to potentially simplify their overall build process.
>>> For instance, this could get rid of extra steps such as filtering 
>>> out dlls that are part of the bundle but were not built as part of 
>>> the jdk (e.g. the Microsoft C and C++ runtime redistributables), or 
>>> making sure that 'exe' and 'dll' files packaged in the .jmod files 
>>> are also signed.
>>>
>>> As a stated before a very similar option already exists for code 
>>> signing on the macOS platform, which further reinforce my thinking 
>>> that such a feature would make sense for Windows as well.
>>>
>>> I have drafted a prototype for this and would be happy to create JBS 
>>> issue and submit a PR to move this forward, provided there is interest.
>>>
>>> Thanks,
>>> Frederic Thevenet (fthevenet)
>>>
>>> [1] 
>>> https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)
>>> [2] https://openjdk.org/jeps/493
>>>
>>
>

From shade at openjdk.org  Wed Feb 26 19:47:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 19:47:55 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v3]
In-Reply-To: <GvrK5bB5jSbbwzRHXMZSYT6-dw6SwrAitDZUCOays40=.540d3b31-7051-40e0-b817-530ae90aa54c@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <GvrK5bB5jSbbwzRHXMZSYT6-dw6SwrAitDZUCOays40=.540d3b31-7051-40e0-b817-530ae90aa54c@github.com>
Message-ID: <FJvJOLW8CLnKbDvIk86MjXQYvhGUVkm8GSP1-eQpGz8=.d470cecb-8731-474b-9a9b-f8b61f2b5659@github.com>

On Wed, 26 Feb 2025 18:24:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename build-linux-x64-static-jdk back to build-linux-x64-static and move close to build-linux-x64-static-libs, for addressing shipilev's suggestions.

Changes requested by shade (Reviewer).

.github/workflows/main.yml line 241:

> 239:       configure-arguments: ${{ github.event.inputs.configure-arguments }}
> 240:       make-arguments: ${{ github.event.inputs.make-arguments }}
> 241:     if: needs.prepare.outputs.linux-x64 == 'true'

Ah, one more trouble: this job produces bundles. But that bundle name is just `linux-x64`, which overrides the standard bundle. See how `build-linux-x64-static-libs` overrides `bundle-suffix:`, do the same here. E.g. `bundle-suffix: -static`?

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

PR Review: https://git.openjdk.org/jdk/pull/23471#pullrequestreview-2645688559
PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972279433

From liach at openjdk.org  Wed Feb 26 19:58:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 19:58:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
Message-ID: <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>

On Wed, 26 Feb 2025 17:23:02 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:
>> 
>>> 214:         } else {
>>> 215:             // simpler adaptation
>>> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)
>> 
>> Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.
>
> I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`

In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972310946

From liach at openjdk.org  Wed Feb 26 19:58:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 19:58:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
Message-ID: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>

On Wed, 26 Feb 2025 17:18:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:
> 
>> 81:                     bb.unsafeGetBase(),
>> 82:                     offset(bb, base, offset),
>> 83:                     handle.be);
> 
> Why do we not have a call to `convEndian` here?

This is just how it was. Refer to line 141 in old diff.

> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:
> 
>> 72:             return ret;
>> 73:         return computeFilterHandle(index);
>> 74:     }
> 
> Why is this using an array, instead of just having 3 fields?

This emulates how MethodHandleImpl does the cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972306931
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972312952

From liach at openjdk.org  Wed Feb 26 20:13:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 20:13:42 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

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

  Jorn vernee review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/c4af6ebf..3d558a2d

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

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

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

From liach at openjdk.org  Wed Feb 26 20:13:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 20:13:42 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>
Message-ID: <k4ITJqaQO-8fY8y4I-wQr1VSDLtQIDqh8gx_8PfcMaY=.401181b9-cf61-40da-a5d9-a49d631bc0ce@github.com>

On Wed, 26 Feb 2025 17:26:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 331:
> 
>> 329: 
>> 330:     @ForceInline
>> 331:     public static int unboxSegment32(MemorySegment segment) {
> 
> Could you add a comment here:
> Suggestion:
> 
>     public static int unboxSegment32(MemorySegment segment) {
>         // this cast to 'int' is safe, because we only call this method on 32-bit platforms, where we know the address of a segment is truncated to 32-bits.

Done, pushed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972329235

From jiangli at openjdk.org  Wed Feb 26 20:18:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 20:18:58 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v3]
In-Reply-To: <FJvJOLW8CLnKbDvIk86MjXQYvhGUVkm8GSP1-eQpGz8=.d470cecb-8731-474b-9a9b-f8b61f2b5659@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <GvrK5bB5jSbbwzRHXMZSYT6-dw6SwrAitDZUCOays40=.540d3b31-7051-40e0-b817-530ae90aa54c@github.com>
 <FJvJOLW8CLnKbDvIk86MjXQYvhGUVkm8GSP1-eQpGz8=.d470cecb-8731-474b-9a9b-f8b61f2b5659@github.com>
Message-ID: <41xF90QH2Ooc7FlWx5AAuka2SHAmVixeJ_JT8f5S5Ck=.2f2477d1-9d4d-4aa0-a249-f1ca33bda327@github.com>

On Wed, 26 Feb 2025 19:44:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Ah, one more trouble: this job produces bundles. But that bundle name is just `linux-x64`, which overrides the standard bundle. See how `build-linux-x64-static-libs` overrides `bundle-suffix:`, do the same here. E.g. `bundle-suffix: "-static"`?

The current `build-linux-x64-static` job doesn't produce any bundles. 

I do agree with your point on overriding the bundle name, as we probably want to include bundle creation in the job at some later point. I actually ran into GHA failure initially when I used the `build-linux.yml` for the job due to bundle name conflict before your https://github.com/openjdk/jdk/pull/23715 change. Updating to include your suggestion for the bundle name...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23471#discussion_r1972340440

From jiangli at openjdk.org  Wed Feb 26 20:25:41 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 20:25:41 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v4]
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <kUANAj43XcScWVvj-abmmKzSr4j5v9twgtNMWO8ED1w=.dc9f7178-1cde-496f-a35e-1c1c0bf6a73d@github.com>

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

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

  Override the default bundle name as suggested by shipilev.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23471/files
  - new: https://git.openjdk.org/jdk/pull/23471/files/6d637c97..91d4c9a1

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

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

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

From jvernee at openjdk.org  Wed Feb 26 20:27:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 20:27:56 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
Message-ID: <MxSiu063m3vUD1fcNcaHIlR0_YbfWD-FVi3EXGN5OjM=.78937390-315e-46a5-bb73-587c7f0f255b@github.com>

On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jorn vernee review

Some more general questions I have: Using which methodology was the performance impact of this patch measured? How can someone reproduce that measurement (now and in the future)? Is there some script or other automation we could add to the repo to do the measurement?

(I have an idea about the answers, but I think it's good to capture the answers here, as part of this review thread, as well)

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2686113353

From liach at openjdk.org  Wed Feb 26 21:36:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 21:36:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
Message-ID: <81ZuUBzSVN9T8h5PsmnA4ETdvpfz-fudKhTEWlrm8Dc=.473909fc-9954-47dc-9d32-58d71bc345c3@github.com>

On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jorn vernee review

I put that 3 lines of code in a `public static void main` and measured the number of instructions executed using bytestacks. Unfortunately we don't have any automation, and this test is partial that we should probably add more things to the measurement (such as general foreign function cost, and cost of other kinds of foreign memory access).

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2686250061

From shade at openjdk.org  Wed Feb 26 22:15:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Feb 2025 22:15:55 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v4]
In-Reply-To: <kUANAj43XcScWVvj-abmmKzSr4j5v9twgtNMWO8ED1w=.dc9f7178-1cde-496f-a35e-1c1c0bf6a73d@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <kUANAj43XcScWVvj-abmmKzSr4j5v9twgtNMWO8ED1w=.dc9f7178-1cde-496f-a35e-1c1c0bf6a73d@github.com>
Message-ID: <Z_iu0x3heFvmFg4dY0Ch2wTbuC90uzooNcXiCuDHtKA=.cfc63bdb-8c64-4e40-a0bb-74ebe8c8fb8c@github.com>

On Wed, 26 Feb 2025 20:25:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Override the default bundle name as suggested by shipilev.

OK, this looks fine. See if @magicus agrees as well.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23471#pullrequestreview-2646071150

From mikael at openjdk.org  Wed Feb 26 22:36:26 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 26 Feb 2025 22:36:26 GMT
Subject: RFR: 8350819: Ignore core files
Message-ID: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>

Core files may from time to time end up in the source tree of the JDK, adding noise in git etc. Because we have valid files and directories called "core*" in the tree it's non-trivial to exclude any and all core files, but as a special case we can at least ignore `core.[0-9]*` which is the typical format used for linux core files. We don't have any such files/directories at the moment and it's unlikely we ever will.

Testing:

* Manually verified that core files are ignored as expected, both in the top directory and in subdirectories
* tier1 + builds-tier[2-5]

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

Commit messages:
 - Exclude core.pid files

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

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

From erikj at openjdk.org  Wed Feb 26 23:09:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 26 Feb 2025 23:09:52 GMT
Subject: RFR: 8350819: Ignore core files
In-Reply-To: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
References: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
Message-ID: <OOlC7p5SBEai5XaqpzWRZ8tnZOLGBlrvkoHRZNkk58k=.46824ada-a23b-4317-880f-06cab6995270@github.com>

On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Core files may from time to time end up in the source tree of the JDK, adding noise in git etc. Because we have valid files and directories called "core*" in the tree it's non-trivial to exclude any and all core files, but as a special case we can at least ignore `core.[0-9]*` which is the typical format used for linux core files. We don't have any such files/directories at the moment and it's unlikely we ever will.
> 
> Testing:
> 
> * Manually verified that core files are ignored as expected, both in the top directory and in subdirectories
> * tier1 + builds-tier[2-5]

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23815#pullrequestreview-2646155008

From ihse at openjdk.org  Wed Feb 26 23:13:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 26 Feb 2025 23:13:52 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64 [v4]
In-Reply-To: <kUANAj43XcScWVvj-abmmKzSr4j5v9twgtNMWO8ED1w=.dc9f7178-1cde-496f-a35e-1c1c0bf6a73d@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <kUANAj43XcScWVvj-abmmKzSr4j5v9twgtNMWO8ED1w=.dc9f7178-1cde-496f-a35e-1c1c0bf6a73d@github.com>
Message-ID: <j1r61fgwGfqg9xYwAES0Zv2VgMiYRMpv4iaHbBgFw-g=.40888433-3225-45dc-b5ae-a14b0693463b@github.com>

On Wed, 26 Feb 2025 20:25:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Override the default bundle name as suggested by shipilev.

Yeah, looks good. Thanks @shipilev and @jianglizhou for getting this better solution than the initial proposal.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23471#pullrequestreview-2646168151

From ihse at openjdk.org  Wed Feb 26 23:18:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 26 Feb 2025 23:18:03 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
 <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
Message-ID: <7XK1RpofZK2eQy9aJyzCMT5r1P1U72Q-apLRaLCAKJo=.8c123b39-1e86-4564-a998-e2238b8d3bc8@github.com>

On Tue, 25 Feb 2025 15:36:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds. The first attempt was buggy in multiple ways and had to be backed out.
>> 
>> This is the description of the original bug report:
>> 
>> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how automatic variables without an initializer should be initialized. The default choice is "uninitialized", which is the default C/C++ behavior. Alternatives are "pattern" and "zero". For improved debugging, helping to detect uninitialized uses, the "pattern" choice should be used.
>
> 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 four commits:
> 
>  - Merge branch 'master' into auto-var-init-redo
>  - Try filtering out -ftrivial-auto-var-init=pattern for libsleef. This patch is getting uglier by the minute...
>  - Only add flag if it is supported
>  - 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

Thanks Erik. I'm still waiting for input from @kimbarrett regarding test_tribool.cpp.

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

PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2686419705

From jiangli at openjdk.org  Wed Feb 26 23:26:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 23:26:58 GMT
Subject: RFR: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <rPwmv6nli7s5b-ThGFeh0ughXzchNy3a8HMoVPkQiJY=.8e43aedb-ddf1-4258-aa31-3afd8eaa26e0@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
 <rPwmv6nli7s5b-ThGFeh0ughXzchNy3a8HMoVPkQiJY=.8e43aedb-ddf1-4258-aa31-3afd8eaa26e0@github.com>
Message-ID: <y6vmW9twvORep64kfI8OQNxQIOJgeSh66EW611mzqlo=.a1367fda-ae93-4270-b98c-9f1b5be9c3b4@github.com>

On Wed, 26 Feb 2025 15:02:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
>> 
>> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
>> 
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020
>
> #23715 should now be in. Now you can just add a clean separate job for this, like this one:
> https://github.com/openjdk/jdk/blob/bd112c4fab8c6b6a8181d4629009b6cb408727a1/.github/workflows/main.yml#L228-L245
> 
> And then you don't need a whole new script for static-jdk build.

@shipilev @magicus Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23471#issuecomment-2686429109

From jiangli at openjdk.org  Wed Feb 26 23:26:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Feb 2025 23:26:58 GMT
Subject: Integrated: 8349399: GHA: Add static-jdk build on linux-x64
In-Reply-To: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
References: <s8AELfEJ7_yVCCNomJOXWscQRCzdfXynXWlON3ONM-k=.6548842a-002a-4341-a203-e3799fcae945@github.com>
Message-ID: <6bUIZgssg_bt6Ilflrlzc1819M7j85mgw2vxL5RFfxo=.e1d82c0f-4097-4ffc-be3c-acbdd629b22b@github.com>

On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds a `linux-x86-static` job in GHA. The job builds the `static-jdk-image` release binary on linux-x64. Please see  https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for some additional context.
> 
> A `debug` build job (building `static-jdk-image` fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the `fastdebug` build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789. 
> 
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020

This pull request has now been integrated.

Changeset: 78c18cfb
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78c18cfbcee92ba170810582e238b40b64805e5a
Stats:     18 lines in 1 file changed: 18 ins; 0 del; 0 mod

8349399: GHA: Add static-jdk build on linux-x64

Reviewed-by: shade, ihse

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

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

From dholmes at openjdk.org  Thu Feb 27 01:37:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Feb 2025 01:37:03 GMT
Subject: RFR: 8350819: Ignore core files
In-Reply-To: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
References: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
Message-ID: <GVxl2HpImr1gg7qQBMSVT4LJ1lc96MZKAg98TLcrMFg=.8eb667be-6690-45b5-a14a-84d39bda614d@github.com>

On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Core files may from time to time end up in the source tree of the JDK, adding noise in git etc. Because we have valid files and directories called "core*" in the tree it's non-trivial to exclude any and all core files, but as a special case we can at least ignore `core.[0-9]*` which is the typical format used for linux core files. We don't have any such files/directories at the moment and it's unlikely we ever will.
> 
> Testing:
> 
> * Manually verified that core files are ignored as expected, both in the top directory and in subdirectories
> * tier1 + builds-tier[2-5]

LGTM. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23815#pullrequestreview-2646326299

From jvernee at openjdk.org  Thu Feb 27 10:30:06 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 10:30:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
Message-ID: <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>

On Wed, 26 Feb 2025 19:56:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:
>> 
>>> 72:             return ret;
>>> 73:         return computeFilterHandle(index);
>>> 74:     }
>> 
>> Why is this using an array, instead of just having 3 fields?
>
> This emulates how MethodHandleImpl does the cache.

Ok. I think the benefit is that each element is individually lazy initialized. I'm not sure about the setup with the array though. It seems like having 3 stable fields would be simpler? Or maybe just initialize them up front in clinit, since they are mostly used together. That would also avoid the need to create a `Lookup` every time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973301941

From liach at openjdk.org  Thu Feb 27 13:27:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 13:27:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
Message-ID: <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>

On Thu, 27 Feb 2025 10:26:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This emulates how MethodHandleImpl does the cache.
>
> Ok. I think the benefit is that each element is individually lazy initialized. I'm not sure about the setup with the array though. It seems like having 3 stable fields would be simpler?
> 
> Or maybe just initialize them up front in clinit, since they are mostly used together. That would also avoid the need to create a `Lookup` every time, which might help performance since that method is CallerSenstive, so we need to do a stack walk to get the caller when running in the interpreter.

Well, the reason I removed the eager init is that their creation in clinit is super costly. Also I think one pair of getter + creator is better than 3 pairs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973576054

From jvernee at openjdk.org  Thu Feb 27 14:20:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:20:16 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
Message-ID: <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>

On Thu, 27 Feb 2025 13:24:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> ...  creation in clinit is super costly

You mean because threads can not race to initialize? I'd think the extra walks to create 3 lookups might offset that though...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973668377

From jvernee at openjdk.org  Thu Feb 27 14:24:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
Message-ID: <pZm9yNcYzgZV499OVNRwQdsZjP_D9bjeXfr4k2UPhe0=.33f1992d-212c-45bf-aca7-8c08ce852b22@github.com>

On Wed, 26 Feb 2025 19:53:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:
>> 
>>> 81:                     bb.unsafeGetBase(),
>>> 82:                     offset(bb, base, offset),
>>> 83:                     handle.be);
>> 
>> Why do we not have a call to `convEndian` here?
>
> This is just how it was. Refer to line 141 in old diff.

Ah, right, the unaligned Unsafe routines support specifying the endianess already, but for the aligned variants it has to be emulated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973675226

From jvernee at openjdk.org  Thu Feb 27 14:24:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
Message-ID: <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>

On Wed, 26 Feb 2025 19:54:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`
>
> In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.

Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973677125

From liach at openjdk.org  Thu Feb 27 15:43:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 15:43:25 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v4]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <aPHkpINA-c_CogUvT7q3d9t8lbcsLZd4eZ1RZzcN6bA=.27569d59-65ea-48fc-ae46-fd331d50931f@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

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

 - Rollback lazy Segment adapter cache per vernee, fix header indent
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Jorn vernee review
 - Review remarks, dates, some more simplifications
 - More cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Make sure the form impl class is initialized
 - Reduce MT initialization work
 - MH linkToStatic stall
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - ... and 4 more: https://git.openjdk.org/jdk/compare/23dee8fd...d59ff23a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/3d558a2d..d59ff23a

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

  Stats: 13038 lines in 332 files changed: 7301 ins; 4580 del; 1157 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

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

From liach at openjdk.org  Thu Feb 27 16:00:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 16:00:47 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

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

  noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/d59ff23a..e5839fb8

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

  Stats: 606 lines in 6 files changed: 28 ins; 30 del; 548 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

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

From jvernee at openjdk.org  Thu Feb 27 16:05:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 16:05:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
Message-ID: <cjJJ0RRvf_vKt5B0kTguGn0_9x7g4UuUVDnCBNl_OS0=.c0a373c4-9069-48bd-af54-2d2941b0b9c9@github.com>

On Thu, 27 Feb 2025 16:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

Latest version looks good.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2648300971

From duke at openjdk.org  Thu Feb 27 16:10:17 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Thu, 27 Feb 2025 16:10:17 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v8]
In-Reply-To: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
Message-ID: <FIJZyYz1by3AjQ07YF_KdQV7rbvZ6HYdy449A6AcoMo=.d05a2d0f-33ee-43a3-a32b-23f146c1fb71@github.com>

> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
> 
> Use the additional information in the "summary" block printed at the end of `make test` target.

Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from magicus/fix-skipped-tests
   
   Fix so skipped tests are not considered failures
 - Fix so skipped tests are not considered failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22245/files
  - new: https://git.openjdk.org/jdk/pull/22245/files/6af586a2..0912b019

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

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

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

From ihse at openjdk.org  Thu Feb 27 16:15:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 27 Feb 2025 16:15:05 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v8]
In-Reply-To: <FIJZyYz1by3AjQ07YF_KdQV7rbvZ6HYdy449A6AcoMo=.d05a2d0f-33ee-43a3-a32b-23f146c1fb71@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <FIJZyYz1by3AjQ07YF_KdQV7rbvZ6HYdy449A6AcoMo=.d05a2d0f-33ee-43a3-a32b-23f146c1fb71@github.com>
Message-ID: <pNSNWFqkGA3uMPCQPZ0ks9LqtGXnbz9vjdq8ECf70jM=.54156844-3a64-413b-8990-1bdbafc30827@github.com>

On Thu, 27 Feb 2025 16:10:17 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #1 from magicus/fix-skipped-tests
>    
>    Fix so skipped tests are not considered failures
>  - Fix so skipped tests are not considered failures

Looks good now to me. Technically, I assume it would be good if you get a re-review of the latest commit, since I should not be reviewing my own code.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22245#pullrequestreview-2648329385

From erikj at openjdk.org  Thu Feb 27 16:36:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Feb 2025 16:36:54 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v8]
In-Reply-To: <FIJZyYz1by3AjQ07YF_KdQV7rbvZ6HYdy449A6AcoMo=.d05a2d0f-33ee-43a3-a32b-23f146c1fb71@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <FIJZyYz1by3AjQ07YF_KdQV7rbvZ6HYdy449A6AcoMo=.d05a2d0f-33ee-43a3-a32b-23f146c1fb71@github.com>
Message-ID: <OomwDFG8pQ3ys08FuXTxRxRzYoFVWJfzrXNN9Wye2K0=.d91b783b-d790-47ce-8b8b-3b4b77ce7e7f@github.com>

On Thu, 27 Feb 2025 16:10:17 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

>> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
>> 
>> Use the additional information in the "summary" block printed at the end of `make test` target.
>
> Ivan Bereziuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #1 from magicus/fix-skipped-tests
>    
>    Fix so skipped tests are not considered failures
>  - Fix so skipped tests are not considered failures

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22245#pullrequestreview-2648404873

From ccheung at openjdk.org  Fri Feb 28 00:37:24 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 28 Feb 2025 00:37:24 GMT
Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v4]
In-Reply-To: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
References: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
Message-ID: <d7y5WjS6GLjV2lnMbAWOoPwpl_OaYeEFhz58SwCFjQE=.c5946b8d-b23d-49dc-aeca-bf962212bbbb@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23758/files
  - new: https://git.openjdk.org/jdk/pull/23758/files/4703c943..2e6a55a6

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

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

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

From ccheung at openjdk.org  Fri Feb 28 00:37:24 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 28 Feb 2025 00:37:24 GMT
Subject: RFR: 8348028: Unable to run gtests with CDS enabled [v3]
In-Reply-To: <JHGN88hwwBpYeT58BqPL970OzasteVumoeBo0PcDUxA=.ba5fe760-5596-40e9-a58b-5982f3e0618f@github.com>
References: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
 <PqAXBC8zSN2Zcrg_YheItdUNtwp2pqqVpYDBQhm0UEA=.e728b8af-28ed-4f9f-a63b-b7229cea98eb@github.com>
 <3oESTZHj_E0KoKAe6DEtvL-SH4L5q6CZidQRXG6k3gQ=.8906fabb-7ff9-4dcc-9518-9e14bd315741@github.com>
 <e0qACcPh8yFsJH6qiE_GZRGy1fbY8-qcVlZReMNR64k=.33835f09-a571-40b5-96cb-e1080fddd8a5@github.com>
 <ZMShukDtobI357aCbnovOHmvgUnKg9_5_F-bDUMQMfE=.80295012-d6e6-4742-94bc-03d334fc6595@github.com>
 <JHGN88hwwBpYeT58BqPL970OzasteVumoeBo0PcDUxA=.ba5fe760-5596-40e9-a58b-5982f3e0618f@github.com>
Message-ID: <J8SZPsuiC4FhYtnHSfv5CVt5hzwF2VPp1TJDSuAJGGE=.01aaf4be-e8f2-4078-ad28-d7fc0f97b32c@github.com>

On Thu, 27 Feb 2025 15:58:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is completely wrong.
>> 
>> The JVM_CFLAGS_FEATURES should be used to add feature-specific flags, not like this. If we really did want to add this to the CFLAGS for all Hotspot files, the correct thing to do would be to add it to JVM_CFLAGS in JvmFlags.gmk.
>> 
>> However, that is not something we want to do. I fully agree with Julian. This is a specific patch needed for one file only, and it should be added just for this particular file. Compare how this is done for e.g. `abstract_vm_version.cpp` in CompileJvm.gmk.
>
> Maybe we can add a new API `const char* Abstract_VM_Version::vm_variant()` that returns the value defined `-DJVM_VARIANT`? Files like os_*cpp and CDS can call this function to get the string such as "server" or "client".

I've pushed another commit based on the above comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23758#discussion_r1974546276

From jiangli at openjdk.org  Fri Feb 28 01:45:34 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Feb 2025 01:45:34 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
Message-ID: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>

Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.

Tested on static JDK locally
GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

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

Commit messages:
 - Remove unused `nVMs` variable.
 - Remove JNI_GetCreatedJavaVMs call.

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

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

From iklam at openjdk.org  Fri Feb 28 02:02:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 28 Feb 2025 02:02:11 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: <lVxjK_giMSnsSNwPFpr4J5Xnjwk7VqWpOlYqW4xkkDk=.07808fbc-392d-48c7-b0da-d6daa6d1fe8b@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

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2649512032

From dholmes at openjdk.org  Fri Feb 28 02:12:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Feb 2025 02:12:53 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: <JgUXa8o5GugdMPQ4sllPsp60J48H9OPQRz9Vs-cO5eE=.5af9c03c-9162-413a-a724-faacec6617a4@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

I like this approach as it addresses the real issue - that we need to know the variant name to find the right directory.

The jvm_path logic in os_bsd is completely broken so we should look at cleaning that up separately.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2649521617

From duke at openjdk.org  Fri Feb 28 07:25:52 2025
From: duke at openjdk.org (mScott224)
Date: Fri, 28 Feb 2025 07:25:52 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <xNDfNtxTIJEpH26bCh0qKskX3T5mwuzQ7nPUaIXyRL4=.faeac4f1-49d7-4e34-a8ca-8db44f84d30f@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

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

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

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2649953250

From duke at openjdk.org  Fri Feb 28 07:30:53 2025
From: duke at openjdk.org (mScott224)
Date: Fri, 28 Feb 2025 07:30:53 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <rCUWN8zzq8Ktyu1LGumKox3U51_f-JETLA-2bdcUhuY=.51cbd0a7-da5e-4cc7-b2f2-bd9c1c867b47@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

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

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

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2649962832

From ihse at openjdk.org  Fri Feb 28 10:23:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 28 Feb 2025 10:23:58 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: <cAaO6ShmODJ76TiqXq5xRhlciT18uYK832kLbic1cNE=.ed6fa58b-746d-4eb2-8c45-60c42a6af925@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

This looks good from a build perspective!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23758#pullrequestreview-2650346184

From mcimadamore at openjdk.org  Fri Feb 28 10:24:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
 <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
Message-ID: <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>

On Thu, 27 Feb 2025 14:21:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.
>
> Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?

(I suggested renaming to something that didn't contain the term "offset" -- it's a subjective thing and if I'm in the minority that's ok. Maybe `noIndex`, or `noVariableOffset` ?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975171803

From kbarrett at openjdk.org  Fri Feb 28 10:32:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 28 Feb 2025 10:32:04 GMT
Subject: RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in
 debug builds [v2]
In-Reply-To: <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
References: <vfBIeiKYvJH3aUkF4SHCl0czFYcxbdlcuRM5mXjJg9w=.10cfe74d-7722-4c5d-84b6-deaf13cbdeaf@github.com>
 <96bwDLFzOWxRWIlc6RTLwp8V5bBqe3ktZvUGDoJfpkk=.a134c3c7-f7e7-4c50-b5ad-23d589f4d33a@github.com>
Message-ID: <l1a7R67h7fI8gE_6yJZbIlggdvARQdi05esoH6cM_AI=.78902aa4-3e8f-454e-b89a-c2b741602d89@github.com>

On Tue, 25 Feb 2025 15:36:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds. The first attempt was buggy in multiple ways and had to be backed out.
>> 
>> This is the description of the original bug report:
>> 
>> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how automatic variables without an initializer should be initialized. The default choice is "uninitialized", which is the default C/C++ behavior. Alternatives are "pattern" and "zero". For improved debugging, helping to detect uninitialized uses, the "pattern" choice should be used.
>
> 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 four commits:
> 
>  - Merge branch 'master' into auto-var-init-redo
>  - Try filtering out -ftrivial-auto-var-init=pattern for libsleef. This patch is getting uglier by the minute...
>  - Only add flag if it is supported
>  - 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

I've run across a couple of internet comments suggesting this option might not
be so great to use, because it can prevent other tools (like valgrind) that
detect uninitialized variables from working. I was expecting that to be an
issue for ubsan, but it seems the uninitialized checking is in MemorySanitizer
(MSan) rather than ubsan.

I think we still want this new option, but maybe there should be some way to
turn it off?  Either with a configure argument explicitly, or a way for
enabling something like msan (which we don't currently support) to disable
this warning.

I believe (but haven't verified) that clang has this same option. We should
work to turn it on too. (Doing so might introduce a different set of needed
exclusions.)

Visual Studio provides a similar mechanism, InitAll.  There's a discussion of
it in the middle of this blog post:
https://msrc.microsoft.com/blog/2020/05/solving-uninitialized-stack-memory-on-windows/
We should work to turn that on too, again subject potentially another set of
exclusions.

Regarding the tribool exclusion, I'm okay with that.  I've figured out how to
deal with it, but am thinking about doing so as part of some additional
tidying up of the tribool stuff.

So this change looks good to me, but I think there is followup work to do.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22691#pullrequestreview-2650362471

From mcimadamore at openjdk.org  Fri Feb 28 10:35:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
 <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
Message-ID: <IFo9I0v2t7sJJuCUXqsRc9mmPl0qgVYOpr230yXlk50=.0a620658-79bc-4ed9-9e1e-7d4da98ce7ac@github.com>

On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
>> 
>> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
>> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
>> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
>> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
>> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
>> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
>> Loo...
>
> Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

> Unfortunately no. I don't really know about the Foreign Memory API as I only started to investigate its performance bottlenecks recently. @mcimadamore or @JornVernee were more involved in the development and likely know better.

After a chat with @PaulSandoz , it seems like the exclusion was not a deliberate one. Probably, sub-int atomic unsafe primitives were added in parallel with the var handle work:

https://github.com/openjdk/jdk/commit/e663206d

The above commit did add support for sub-word atomics, but only in the field access case. The BB view/array view var handles were left out. Then came FFM, whose implementation was originally based off the BB view var handle -- so we ended up inheriting same limitations.

It would be good to address this -- in a separate PR. As for this PR, as we discussed offline, I'd suggest to keep the ScopedMemoryAccess changes (even if some methods are now unused) and drop the commented lines from the var handle gensrc file. Then we can come back with a new PR and add support for missing access modes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2690284867

From mcimadamore at openjdk.org  Fri Feb 28 10:35:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
 <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
Message-ID: <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>

On Thu, 27 Feb 2025 14:17:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Well, the reason I removed the eager init is that their creation in clinit is super costly. Also I think one pair of getter + creator is better than 3 pairs.
>
>> ...  their creation in clinit is super costly
> 
> You mean because threads can not race to initialize? I'd think the extra stack walks to create 3 lookups might offset that though...

Another possible option -- if we don't like this, is to put the constants in an holder class. As @JornVernee  says, most of the times the fields are used together. Re. initialization cost, I agree with @liach as I have observed the same thing -- these helper method handles lead to some bytecode spinning -- which is better to delay if not strictly needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975182862

From mcimadamore at openjdk.org  Fri Feb 28 10:35:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
 <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
 <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>
Message-ID: <VyWFtRvSy2Q_NhI86349UK3Q9AH1bPRYkLIPyzWWMFE=.27e29f07-dcf0-496d-b4ff-a80e0d9e8fd8@github.com>

On Fri, 28 Feb 2025 10:29:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I have observed the same thing -- these helper method handles lead to some bytecode spinning

Although - that was before; in the new code these helpers don't do adaptation... so it should be ok. (I also see the code has been updated)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975185780

From mcimadamore at openjdk.org  Fri Feb 28 10:43:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:43:08 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
 <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
 <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>
Message-ID: <anavQ_b94qrDKB0akrzR4krG0GAEMKNE9ZV68hVglqI=.52162b38-4deb-4d95-9a1c-75cda1e867b7@github.com>

On Tue, 25 Feb 2025 14:39:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Left a space and an extra note to make the comment hash more obvious.
>
> Unless you plan to shortly push a new PR where you either enable this functionality, or remove the commented-out lines, I strongly prefer *not* to have commented-out code in the makefiles. It's not that hard to re-create these lines should they be needed. And you can always find the history in this PR.

Yes, let's drop this for now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975196301

From mcimadamore at openjdk.org  Fri Feb 28 10:43:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:43:10 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
Message-ID: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>

On Thu, 27 Feb 2025 16:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 53:

> 51: 
> 52:     static final VarForm CONSTANT_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class);
> 53:     static final VarForm TAKE_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class, long.class);

what does TAKE mean here? (the old names weren't great either, I realize). I think it would be better to decide, once and for all, how to refer to these things, and then use consistent naming throughout. I see we have discussed using "noStride" vs. "fixedOffset". Since the implementation now uses the term "constantOffset", let's just call the other "variableOffset" ?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 120:

> 118: 
> 119: // This class must be accessed through non-aligned VarHandleSegmentAs$Type$s
> 120: final class VarHandleSegmentAs$Type$sAligned extends VarHandleSegmentAs$Type$s {

I kind of liked the nested classes -- why the change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975192481
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975193951

From ihse at openjdk.org  Fri Feb 28 10:44:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 28 Feb 2025 10:44:58 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
 <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
Message-ID: <n-tT5evU9GasQDZUxXYASLUIW_VdSJKwtebQ90qY-h8=.1e7330df-8555-4372-b5d0-ea1ba4159085@github.com>

On Wed, 26 Feb 2025 13:24:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.
>> 
>> Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.
>> 
>> I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:
>> 
>> 
>>    OPT_gcc_clang := -O1, \
>>    OPT_microsoft := -O2. \
>> 
>> 
>> since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.
>
>>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.
> 
> Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
> Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
> Seems I can edit the pages there but not create a new one , can you !?

@MBaesken I don't know why you could not add new pages (everyone in the Build Group should be able to do that). The UI is a bit strange, I usually create a new page by creating a tentative link from an existing one.

Anyway, I created https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research. It's all yours!

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

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

From mbaesken at openjdk.org  Fri Feb 28 11:11:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 11:11:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
 <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
Message-ID: <RaH0aEew1LaH3oBPaP9EGf2BLN6BFvdCDKI6tzyLDJc=.fa20ae4c-1b09-491e-9aa7-d0c575026a7d@github.com>

On Wed, 26 Feb 2025 13:24:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.
>> 
>> Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.
>> 
>> I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:
>> 
>> 
>>    OPT_gcc_clang := -O1, \
>>    OPT_microsoft := -O2. \
>> 
>> 
>> since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.
>
>>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.
> 
> Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
> Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
> Seems I can edit the pages there but not create a new one , can you !?

> @MBaesken I don't know why you could not add new pages (everyone in the Build Group should be able to do that). The UI is a bit strange, I usually create a new page by creating a tentative link from an existing one.
> 
> Anyway, I created https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research. It's all yours!

Thanks ! I'll most likely have some time next week to collect and add some info from our build envs we use at SAP.

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

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

From duke at openjdk.org  Fri Feb 28 12:57:08 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 28 Feb 2025 12:57:08 GMT
Subject: RFR: 8343832: Enhance test summary with number of skipped tests
 [v7]
In-Reply-To: <4Gwqsj45uGnAXA4RTeCaeqjspwLHW-fGkW-b0GdyRA8=.e541f5a8-6975-458a-808c-202a8f01397c@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
 <7TMRtxis-cm6REnZZJIWfZHvH5PE7gmmEuf_qUsnPMo=.004bc017-c4cb-4268-a3ea-eb0fa38f89b7@github.com>
 <4Gwqsj45uGnAXA4RTeCaeqjspwLHW-fGkW-b0GdyRA8=.e541f5a8-6975-458a-808c-202a8f01397c@github.com>
Message-ID: <XyYF3He0YMiW9hX5Z0_WMPgR66RYXLAux0PYiA1sZ8o=.01e59edc-6547-462a-9d82-2d51b1331465@github.com>

On Wed, 26 Feb 2025 19:07:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ivan Bereziuk 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 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8343832_enhance_test_summary
>>  - Merge branch 'master' into 8343832_enhance_test_summary
>>  - SKIPPED is always zero for Microbenchark testing. Define SKIPPED in one go after branching.
>>  - _SKIPPED was not defined for gtest and special tests. Treat disabled gtests as _SKIPPED
>>  - adapt changes to the ancient awk on MacOS
>>  - Merge branch 'master' into 8343832_enhance_test_summary
>>  - indented the comment
>>  - remove resorting zero-ing of $1_SKIPPED as preceding gawk always assigns the value
>>  - lowercased Jtreg. fixed typos in the comment
>>  - aggregated calculation for many categoires of skipped tests into one gawk block with regex
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1deac5ce...6af586a2
>
> Actually, my assessment was wrong -- it is not the GHA script that is the cause of failure. Instead, it was the changes in RunTests.gmk that were not complete. They tried to detect if there were any errors by comparing the number of successful tests with the total number of tests, but this is no longer an uphold invariant. Another side effect of this was that even when run locally, tests suites with passed tests would be marked as failed.
> 
> It was a bit tricky to describe what was needed for this, so I made a patch at 
> https://github.com/openjdk/jdk/commit/6784dea42c60b720027b291dfd8263ad175b4ab0. This is currently running in GHA at https://github.com/magicus/jdk/actions/runs/13551422706, but I expect it to pass, since the script behaves properly local on my computer.

Thank you, @magicus, @erikj79 for helping me with this MR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22245#issuecomment-2690583671

From liach at openjdk.org  Fri Feb 28 13:35:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 13:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
 <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
Message-ID: <cCTIEbnZzNbC6wjBSB9zgbiDUU2oyeXT59yMWop1wN8=.2a960ccc-6b2a-46c5-8982-e83057275e7b@github.com>

On Fri, 28 Feb 2025 10:38:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 120:
> 
>> 118: 
>> 119: // This class must be accessed through non-aligned VarHandleSegmentAs$Type$s
>> 120: final class VarHandleSegmentAs$Type$sAligned extends VarHandleSegmentAs$Type$s {
> 
> I kind of liked the nested classes -- why the change?

Nesting means we need to define 3 classes: AsXxx, Unaligned, Aligned. I wish to reduce class loading by merging AsXxx and Unaligned. The Aligned still works as if it is nested, but I put it out to make the indentation beautiful for boolean and byte.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975417166

From liach at openjdk.org  Fri Feb 28 13:35:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 13:35:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
 <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
 <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>
Message-ID: <gk8c26xHhO3St3ZR_0hYEzeQx-OOvWBMS064Oy8wpP8=.337a9e91-b8e8-4fa4-9b86-44487e33156d@github.com>

On Fri, 28 Feb 2025 10:21:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?
>
> (I suggested renaming to something that didn't contain the term "offset" -- it's a subjective thing and if I'm in the minority that's ok. Maybe `noIndex`, or `noVariableOffset` ?)

I have already used constantOffset and find it better than noStride in terms of clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975413935

From duke at openjdk.org  Fri Feb 28 13:48:58 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Fri, 28 Feb 2025 13:48:58 GMT
Subject: Integrated: 8343832: Enhance test summary with number of skipped tests
In-Reply-To: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
References: <b2dCK_8gxHx2a1ISR7wAjU6AhTvz3OZVa9NXznyCjbQ=.52ed8689-3733-4ee7-b3b7-0b1bca8789df@github.com>
Message-ID: <geDsBUeZdS91JhrFLBfs1-neGZIERW4jn2nD6_WN7Os=.ab122a60-c988-4318-a533-77484113862a@github.com>

On Tue, 19 Nov 2024 16:15:42 GMT, Ivan Bereziuk <duke at openjdk.org> wrote:

> The output for Jtreg v7.5 was [enhanced](https://github.com/openjdk/jtreg/pull/217/files#diff-b6ab77bf651f1fd9a83c3ca0aab9cd24ae5c08cef41e6e257f7eaccc07c7c366R947) with [information about skipped tests](https://github.com/openjdk/jtreg/blob/master/src/share/doc/javatest/regtest/faq.md#what-do-all-those-numbers-in-the-test-results-line-mean).
> 
> Use the additional information in the "summary" block printed at the end of `make test` target.

This pull request has now been integrated.

Changeset: 2019f445
Author:    Ivan Bereziuk <Navi.Bereziuk at gmail.com>
Committer: Ludvig Janiuk <lujaniuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2019f44539db0e19d92eeb1b4e80b74a6de3276c
Stats:     79 lines in 1 file changed: 60 ins; 6 del; 13 mod

8343832: Enhance test summary with number of skipped tests

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

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

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

From liach at openjdk.org  Fri Feb 28 15:57:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 15:57:18 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

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

  Use "variable offset", remove extra makefile comments, comment fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/e5839fb8..b995a268

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

  Stats: 31 lines in 6 files changed: 4 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

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

From liach at openjdk.org  Fri Feb 28 15:57:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 15:57:19 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
 <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
Message-ID: <46TXxv_4RUZf00NsEsk8tmOVHfQ3j6GJ7foEQo85B7g=.399adafc-5e1b-4efc-b061-52914995bde6@github.com>

On Fri, 28 Feb 2025 10:37:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 53:
> 
>> 51: 
>> 52:     static final VarForm CONSTANT_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class);
>> 53:     static final VarForm TAKE_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class, long.class);
> 
> what does TAKE mean here? (the old names weren't great either, I realize). I think it would be better to decide, once and for all, how to refer to these things, and then use consistent naming throughout. I see we have discussed using "noStride" vs. "fixedOffset". Since the implementation now uses the term "constantOffset", let's just call the other "variableOffset" ?

Done renaming to `VARIABLE_OFFSET_FORM`. I have also cleaned up some other stale names in the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975640481

From mcimadamore at openjdk.org  Fri Feb 28 16:02:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 16:02:04 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <fCBnV08d7pDsscwS-UL4NDr74Am-OQ8JnZKRa-UGXcU=.ed5e28f6-b8fa-4d95-9314-4d6cb1897bae@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Very nice -- thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2651162993

From jwaters at openjdk.org  Fri Feb 28 16:37:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 28 Feb 2025 16:37:01 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <XNz06jGNCQw0e76tYuoBoBfhivU-Aq6x2rF0oL4p06c=.eec98ee4-bd1e-442e-8703-e76acda8ec66@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
 <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>
 <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>
 <XNz06jGNCQw0e76tYuoBoBfhivU-Aq6x2rF0oL4p06c=.eec98ee4-bd1e-442e-8703-e76acda8ec66@github.com>
Message-ID: <loeuo9YE-bK_kzdW4j4s5rCAqJDuHOpg09dZFaeFS2c=.296920d0-baf6-43d4-8262-5f65ca91505e@github.com>

On Tue, 18 Feb 2025 13:44:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > @MBaesken Currently with LTO active on gcc 14 commit [e648a90](https://github.com/openjdk/jdk/commit/e648a907b31fd0d6b746d149fda2a8d5fbe26dc0) is causing serious trouble on my end by mass inlining everything, bloating the JVM to nearly 60MB in size, does HotSpot have the same size issues on your end with LTO? (--enable-jvm-feature-opt-size is off the table because the JVM should ideally be an acceptable size even without that flag, and -Os and LTO doesn't work with gcc anyway)
> 
> On my end we used gcc11 in the past and now test gcc13. Both work nicely, no libjvm.so bloat has been observed with lto. Maybe there is some issue/difference with gcc14 but so far we did not test with this version.

Leaving Kim's comment about flattening in here, as I believe something has changed with the flatten attribute in gcc 14 that made it far more aggressive across compilation units, so this is probably relevant. A simple test of symbol size with nm strongly supports this theory

> G1ParScanThreadState uses ATTRIBUTE_FLATTEN to tune the inlining of code in that class, in an attempt to ensure the desired fast paths are inlined, despite the size and other attributes of some of these functions that might (and empirically did) inhibit inlining in some critical places with at least some compilers. It also uses NOINLINE and assumed implicit non-inlining of definitions in other translation units to keep slower paths out of line, to limit code size. It looks like there are a couple of things going on here.
> 
> One is that slow paths internal to the Stack implementation (and perhaps other places) are being flattened because there isn't any NOINLINE anywhere to prevent it and it's all template code, so source is not in another translation unit. So we're probably generating more inline code that we really want. That seems hard to avoid though.
> 
> The other is that LTO seems to be applying flattening even across translation units. (That's not completely surprising.) So the assumption that the flattening won't apply to code in other TU's is invalidated by LTO. That's going to make flatting a lot harder to use.

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

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

From jvernee at openjdk.org  Fri Feb 28 16:46:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Feb 2025 16:46:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <e432_fOgKqFpPy2Ll4zR03yH3QswWaki6WDl1_XYU1A=.760133a3-0177-4ecd-acda-46ef954d6276@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2651272766

From ccheung at openjdk.org  Fri Feb 28 17:13:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 28 Feb 2025 17:13:03 GMT
Subject: Integrated: 8348028: Unable to run gtests with CDS enabled
In-Reply-To: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
References: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
Message-ID: <8cTzMzXSWY3d09M03BgKaoCUTlMY6xNmyUIxZzG101A=.7f0c6ce9-243f-4558-a865-c8f77b03812f@github.com>

On Tue, 25 Feb 2025 00:51:55 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

This pull request has now been integrated.

Changeset: e98df71d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e98df71d9c5120fbb73a4c2f49863775fe5db781
Stats:     29 lines in 5 files changed: 12 ins; 14 del; 3 mod

8348028: Unable to run gtests with CDS enabled

Reviewed-by: dholmes, iklam, ihse

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

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

From ccheung at openjdk.org  Fri Feb 28 17:13:02 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 28 Feb 2025 17:13:02 GMT
Subject: RFR: 8348028: Unable to run gtests with CDS enabled
In-Reply-To: <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com>
References: <AEFBkhlKGoeaXKagIof-6EDV_GI6Ripc8zjvNRUfFm4=.9ab1a77f-4def-41e4-91ea-b2fb02397b98@github.com>
 <Bzdnt0I9ce6m7bb5rHE8ZaO1qSort0Dnvpf1CAXslk0=.5af032d1-2656-4e88-aac5-3f24f6bb98a7@github.com>
 <YMNtF5iuJdq4Ksu_-AEiiqdWXZjlOQQxamOTV1BEEBU=.8371f2a1-22dd-46d4-955d-d75c8dc809da@github.com>
 <95dWIGdTxTDnkqHDbWojjFWPp7v1_Pjq6tYS0fV1dY4=.5904357f-ed1a-4bd1-8953-6fa3f62038d1@github.com>
Message-ID: <cc_Ddat0u9zBa708TSZlKJTcXMuNKepl7XpaxIJR_Pc=.8f74dcbd-8ad3-473a-b3a6-cc08d17ef333@github.com>

On Thu, 27 Feb 2025 12:42:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Also,
>>> 
>>> > That presumes you are dealing with a single variant JDK, not one that has both client and server.
>>> 
>>> Is this even relevant anymore? Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed.
>> 
>> Don't we still have support for combining every kind of VM (Except Zero) into the resulting JDK or am I mixing it up with something else?
>
>> Afaik, the last platform to have both client and server where 32-bit Windows, which is now removed.
> 
> It is still allowed. Whether anyone actually needs it, or uses it is a different matter. The point is you have to match the gtest variant with the jdk variant.
> 
> EDIT: actually is it still allowed? Does the build system require only a single JVM variant be configured? If not how do the different variants actually get built?

@dholmes-ora, @iklam, @magicus Thanks for the reviews!

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

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

From liach at openjdk.org  Fri Feb 28 20:04:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:04:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <P5UGpZiYwmrB5VUIww3KwQz9HdYTd6tq0kQzvZ4QazE=.bf67f90c-6290-47e1-afe9-0567f621f972@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Tier 1-3 looks good besides some unrelated desktop tests. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2691447859

From liach at openjdk.org  Fri Feb 28 20:04:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:04:07 GMT
Subject: Integrated: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <pJirzD-ZIip_BbPrHox4B7c3jtMM3-3qMBnj7QvlhpQ=.45d95ac5-513b-4cb6-afb0-d3c2014b21d7@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

This pull request has now been integrated.

Changeset: c7fa499b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7fa499bf5023a3f16bb3742d2ba3cd74f2b41bd
Stats:     1720 lines in 18 files changed: 1046 ins; 209 del; 465 mod

8350118: Simplify the layout access VarHandle

Reviewed-by: mcimadamore, jvernee, erikj

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

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

From mikael at openjdk.org  Fri Feb 28 23:36:55 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 28 Feb 2025 23:36:55 GMT
Subject: RFR: 8350819: Ignore core files
In-Reply-To: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
References: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
Message-ID: <iK_y8Cw7J4FYeL5AWw-jzvBa0f1PuDNWqSi1ly6Mvz4=.a7b8c017-a03e-4a6a-93ad-076fa6159216@github.com>

On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Core files may from time to time end up in the source tree of the JDK, adding noise in git etc. Because we have valid files and directories called "core*" in the tree it's non-trivial to exclude any and all core files, but as a special case we can at least ignore `core.[0-9]*` which is the typical format used for linux core files. We don't have any such files/directories at the moment and it's unlikely we ever will.
> 
> Testing:
> 
> * Manually verified that core files are ignored as expected, both in the top directory and in subdirectories
> * tier1 + builds-tier[2-5]

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23815#issuecomment-2691718178

From mikael at openjdk.org  Fri Feb 28 23:36:55 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 28 Feb 2025 23:36:55 GMT
Subject: Integrated: 8350819: Ignore core files
In-Reply-To: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
References: <a4pAbRNSeYm3L-yyNUd-XPDYCjg1eyvNhovQHNJ-jQU=.e5fc87bb-ffe4-4212-ace8-b843320019fd@github.com>
Message-ID: <ugxm15Y0RMYLlMPdUI67Jf62LNt0akfb-C1a0Im25UY=.3900cc75-6dc7-4984-8a96-abde8e51449b@github.com>

On Wed, 26 Feb 2025 22:26:58 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Core files may from time to time end up in the source tree of the JDK, adding noise in git etc. Because we have valid files and directories called "core*" in the tree it's non-trivial to exclude any and all core files, but as a special case we can at least ignore `core.[0-9]*` which is the typical format used for linux core files. We don't have any such files/directories at the moment and it's unlikely we ever will.
> 
> Testing:
> 
> * Manually verified that core files are ignored as expected, both in the top directory and in subdirectories
> * tier1 + builds-tier[2-5]

This pull request has now been integrated.

Changeset: 785e7b47
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/785e7b47e05a4c6a2b28a16221fbeaa74db4db7d
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8350819: Ignore core files

Reviewed-by: erikj, dholmes

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

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